Fabrício G. Araújo

Você ainda está emitindo na versão 3.10 e agora tem que ser a 4.00.

Olá @FabianoCunha, resolvi fazer um teste com a url que está no XML da NFC-e que foi emitida em produção no cliente dia 19/09/2018, e para minha surpresa listou a nota, sem fazer nenhuma alteração no pipe. Então acredito que a Sefaz/GO ajustou a consulta para seguir a especificação da nota técnica corretamente, espero que continue assim.

Ué... SP e CE tem a exigência de equipamento específico (SAT)... não me surpreenderia nenhum pouco... fazer o quê...

@Claudiomir, por aqui a ativamos recentemente em produção (NFC-e 4.0) em MT, e percebemos que vira e mexe acontece algumas instabilidades, como erro de "Erro Interno: 0 Erro HTTP: 404", mas depois volta ao normal. Não sei dizer sobre cancelamento, mas ninguém me relatou nada. Acredito que por esses dias ainda teremos algumas instabilidades, pois as SEFAZ estão correndo para cumprir o prazo e devem estar ajustando seus servidores.

Só uma dica... infelizmente esse site não é muito confiável... pois em GO sempre a bolinha está amarela (nunca vi verde), e por aqui os meus clientes emitem NFC-e normalmente e inclusive na versão 4.00 desde jun/18.

O tópico abaixo foi fechado: Só queria dar continuidade com meu relato, pois consegui autorizar NFC-e no ambiente de Produção em GO, tanto a url que estava antes quando as novas publicadas no post acima, ou seja, em GO não está validando em Produção as urls do qr-code 2.0, aceita qualquer coisa. Testado em Produção com: URL-ConsultaNFCe_2.00=http://www.sefaz.go.gov.br/nfce/consulta e URL-ConsultaNFCe_2.00=http://www.nfce.go.gov.br/post/ver/214344/consulta-nfce O inconveniente de ativar agora o qr-code 2.0 em GO, é que se bipar o código, ainda a Sefaz não está preparada para listar a NFC-e, abrindo um site com mensagem de qr-code inválido. Portanto o que vou fazer é manter o meu sistema já emitindo NFC-e 4.00, mas com qr-code 1.0, então na virada do dia 01/10/2018 (se não adiarem), viro a chave no meu sistema para ativar o qr-code 2.0. Pessoal, como estão se planejando para essa virada?

Já houve uma conversa sobre o assunto aqui: Pelo que entendi, o @FabianoCunha informa que a url em produção está ok, só a de homologação que não... funcionada como você testou mesmo em homologação, igual a da 1.0.

Talvez seja o mesmo caso do MA, chegou a testar não informar a tag do cartão, para isso informe o tpIntegra = tiNaoInformado. No MA a NF-e passa dessa forma.

No seu exemplo, "Produção para Revenda", acredito que não gerou o MVA (pMVAST), porque você não informou nenhum valor para ele, e acredito que pela programação do componente, por se tratar de um campo não obrigatório, ele só é preenchido quando informado um valor. Já no seu exemplo, "Produção uso e Consumo", você utilizou um CSOSN que é um dos mais básicos de todos, que só existem dois campos disponíveis (orig e CSOSN). Dá uma olhada nesse post, que ilustra bem os campos disponíveis para cada tipo de tributação (mas também seria bom verificar a última NT (NT_2016_002_v1_60), que foram criados mais campos):

O que achei estranho no seu XML é que não apareceu o campo pMVAST (Percentual da margem de valor Adicionado do ICMS ST), pois nele é que identificaria o vBCST. Mas contando que o vBCST esteja correto, então aplicando o pICMSST de 25% teríamos 151,45, mas como já temos o vICMS de 100,38, tiramos a diferença, ficando 51,07 (151,45 - 100,38).

@Wellington Monteiro, não intendi direito... mesmo o simples nacional no 900 já possui os campos separados, não é mesmo? Veja:

Imagino se quiser dar uma mensagem mais explicativa para o usuário, então acredito que você mesmo tenha que implementar as restrições em seu sistema antes mesmo que aconteça. Por exemplo, no seu exemplo você permitiu que fosse informado os dados do destinatário sem informar o campo número, então bastaria você colocar essa regra no seu sistema e apresentar a mensagem de restrição bem clara para o usuário e nem sequer você geraria a nota e tentaria enviar nesta situação. Estuda a documentação e veja as regras de preenchimentos, se campos são obrigatório ou que tipo de dado é permitido... e no dia a dia, caso vá identificando mais situações de restrições, então vai incrementando o seu sistema com mais validações.

Valeu por responder... Ufa... pelo menos ainda continua como antes. Infelizmente no MA os dos tipos de notas, NF-e e NFC-e tem regras diferentes em relação ao pagamento à cartão.

@Visual Informática, a sua chave da NFC-e constará o mês 7, inclusive foi quando deu saída da mercadoria, então não importa quando foi autorizada, e sim a data da venda efetivamente.

Obrigado por responder. É também o que pretendo fazer, mas também pretendia (ou pretendo ainda), gerar as informações completas para NFC-e (tpIntegra = 2, com CNPJ, tBand e cAut), pelo menos até ontem não fui reportado sobre problemas em usar o tpIntegra = 2 com NFC-e 4.0, então preencheria completo o xml com as tags correspondente, e também poderia colocar nas informações complementares só para sair no DANFE.

@adilsonpazzini, você enviou NFC-e ou NF-e? Pois até em então, nos meus clientes em produção na versão 4.0 a NFC-e aceita o tpIntegra = 2 (Não integrado) e já a NF-e tive que fazer como a Graça (tpIntegra = tiNaoInformado). Espero que não tenha ocorrido isso em NFC-e, pois até estou adaptando o sistema para passar os demais dados utilizando tpIntegra = 2, com CNPJ, tBand e cAut.

Nossa... que bobeira minha... esses campos realmente não existem no 900 para o simples, conforme as NT. Me desculpem pessoal... se puderem até excluir o tópico para não gerar confusão para outros...

Pessoal, desculpem se estiver enganado, mas acredito que tenha uma falha no componente ao gerar o XML com os dados FCP do ICMS quando a empresa é do Simples Nacional e está utilizando o CSOSN 900. Percebi que está correto o preenchimento para o Regime Normal e CST 90, mas para o simples não tem o preenchimento. Segue em anexo a unit alterada. pcnNFeW.pas

@Gr@c@, estou começando a ser pressionado pelos contadores dos clientes para adequar a essa resolução, por enquanto não faço nenhum tipo de vínculo. Teria como você dar um print de como você está montando o seu DANFE (o que você citou como gambiarra), só para ter uma ideia de como vou fazer o meu.

Isso mesmo @BigWings, os testes que fiz com Qr-Code 2.00 foi sem o http://, funcionou ok. Acredito que esteja tudo ok no ambiente de homologação, pois emiti NFC-e 4.00, tanto com Qr-Code 2.0 como o original, agora em produção só tenho como afirmar que está funcionando NFC-e 4.00 com Qr-Code original, não tive como testar em ninguém com Qr-Code 2.0.

Por favor, se possível, posta o xml gerado para que alguém possa ajudar.

Chegou a conferir o xml gerado se está ok, na versão 4.00, tipo o do lote de envio, por exemplo: xxxxx-env-lot.xml?

@Célio Rafael Martins Júnior, posta o trecho do seu código quando informa no componente a forma de pagamento, já vi aqui muitos darem mais de um Add e não perceberem.

Acredito que seja a mesma situação de MT mesmo, veja a postagem do Daniel S Ferreira: O ideal seria entrar em contato com a SEFAZ/PR para questioná-los da falha da validação deles, pois não estão seguindo a especificação da NF.

@Iago de Assis, veja se você está configurando a NFC-e com a versão 4.00. Cheguei a receber exatamente esse erro quando por engano configurei como versão 3.10 e Qr-Code 2.0.