BigWings

2.2 - Permaneça no assunto - Quando tiver uma dúvida diferente do assunto no tópico, poste em novo tópico. Não use algo equivalente a "aproveitando o gancho... [dúvida não relacionada com o tópico aqui]". Favor leia as regras do fórum.

Para que as alterações no arquivo ACBrNFeServicos.ini sejam enxergadas pela aplicação, você deve: - Copiar o arquivo ACBrNFeServicos.ini para o diretório da aplicação, reiniciando a mesma. ou - Executar o Compila_RES.bat, para gerar o ACBrNFeServicos.res; - Recompilar a aplicação.

Sim, a propriedade SSLLib só existe como atalho para definir as outras três configurações que são usadas pelo componente. A conexão é feita de acordo como o configurado em SSLHttpLib. Veja o vídeo abaixo para mais detalhes:

Qual a UF?

A regra de validação está marcada para 03/09/2018, mas a NT tem data de entrada em vigor em produção no dia 23/07/2018. O esperado é que no dia 23/07/2018 as SEFAZ tenham atualizado os schemas referentes a NT, o que solucionaria o problema de rejeição por falha de schema. Creio que você quis dizer produção. Como não há garantia que as SEFAZ terão atualizado os schemas, a minha sugestão é que deixe False na propriedade CamposFatObrigatorios em produção, ou pelo menos que ela seja ajustável na aplicação.

Se o item tem GTIN, você deve informá-lo nas tags cEAN e cEANTrib. Se o item não tem GTIN, deve informar o literal SEM GTIN. Por enquanto a validação ocorre apenas na NFe 4.00 em homologação. A validação em produção está marcada para implementação futura, a partir de 01/12/2018.

Como dito no tópico acima nos meus testes não consegui simular o erro. Anexe o arquivo xml de envio envelopado (*-ped-rec-soap.xml) para comparação.

Favor continuar aqui:

Sim, a propriedade foi criada justamente por causa dessas inconsistências. Ela deve ser ajustada de acordo com o modo que cada UF está tratando em produção ou homologação.

É sim. Configure a propriedade CamposFatObrigatorios como False.

@GiseleZerbinati está usando o ACBr? Testei aqui e o retorno foi normal. Anexe o arquivo XML envelopado (*-ped-rec-soap.xml) enviado para o webservice, para comparação.

Sim, o gerador verifica se qualquer um dos campos está preenchido e gera ambos se for o caso: if (nfe.Det[i].Imposto.ICMS.UFST <> '') or (nfe.Det[i].Imposto.ICMS.pBCOp <> 0) or (nfe.Det[i].Imposto.ICMS.CST = cstPart10) then begin Gerador.wCampo(IIf(Usar_tcDe4,tcDe4,tcDe2), 'N25', 'pBCOp ', 01, IIf(Usar_tcDe4,07,05), 1, nfe.Det[i].Imposto.ICMS.pBCOp, DSC_PBCOP); Gerador.wCampo(tcStr, 'N24', 'UFST ', 02, 02, 1, nfe.Det[i].Imposto.ICMS.UFST, DSC_UFST); end;

O mesmo vale para a tag UFST, informe a mesma em branco.

O ACBrMonitorPLUS não tem comando para fazer a configuração das casas decimais na impressora. O comando DecimaisPreco apenas retorna o estado atual. Tente um utilitário da ECF para fazer a programação... é possível que isso só possa ser feito em modo de intervenção técnica.

Na NFe 3.10 havia uma única tag indPag por NFe para indicar o tipo de pagamento. Na NFe 4.00 ela foi removida e inserida novamente mas agora pode ser informada para cada pagamento da NFe. A tag pag.indPag não é obrigatória então, caso não informada não será gerada no XML. Caso deseje, informe pag.indPag diferente de ipNenhum. A NT não previu a impressão dos dados dos pagamentos no DANFE.

Deve ser liberada nova versão hoje, para os usuários SAC, já com as URLs atualizadas. Você também pode tentar apenas substituir o arquivo ACBrNFeServicos.ini com o abaixo: https://svn.code.sf.net/p/acbr/code/trunk2/Fontes/ACBrDFe/ACBrNFe/ACBrNFeServicos.ini As novas URL aceitam apenas conexão via TLS 1.2 então verifique as configurações SSLLib.

Estranho.. pode fornecer um XML para análise?

Chegou a atualizar os fontes? A propriedade CamposFatObrigatorios deve ser ajustada para cada UF e ambiente, como bem explicado pelo André no topo do tópico.

A validação é obrigatória em NFe interestadual (exceto NFe avulsa), e facultativa, a critério de cada UF, em NFe intermunicipal.

Acredito que isso seja causado por se estar usando a versão "basic" do FastReport (a que vem junto com o Delphi), por ela não ter suporte a scripts.

Foi atualizado no dia:

Me parece que é justamente esse o problema, nesse dia não haverá a hora 00:00, já que a hora será adiantada em 1 hora a partir de 20/10/2018 23:59:59 direto para 21/10/2018 01:00:00. https://github.com/JodaOrg/joda-time/issues/146 Provavelmente o webservice está tratando o campo como data e hora, e o campo sendo apenas data, é inferida a hora 00:00:00. Quem está tendo o problema precisa reportar a SEFAZ.