BigWings

ACBrBoletoConversao

Pela mensagem parece estar repetindo endereço de email na lista "para" e "cc".

Que saiba não tem métodos faltando no eFrete. Você tem manual ou indicação que o webservice implementa esses métodos de consulta?

Está usando eFrete?

Tentou definir desta forma: Formato: tdetMascara MaskqCom: ,0.####

Geralmente a raiz C:\ é protegido. Se não for pelo Windows um antivírus pode estar bloqueando. Já tentou fazer a gravação em uma pasta interna?

No caso era adicionar apenas "System" no unit scope names, mas que bom que resolveu.

O ACBrNFeServicos.ini já está correto com a nova URL, você precisa apenas configurar o componente para a versão 4.00.

Digo qual modelo está selecionando para exportar o arquivo. Para balanças Toledo existem os modelos modToledo, modToledoMGV5, modToletoMGV6 e modToledoMGV5Ver1. Dependendo de qual gerenciador for usar para importar os arquivos, e a versão, pode gerar resultado diferente. Pelo que vi no código para modToledo realmente não está gerando o arquivo de teclas, mas as demais estão. Sobre a função de cada uma, Tecla é a associação do teclado da balança com o produto para não precisar digitar o código, e Validade é a quantidade de dias de validade do item para ser impresso na etiqueta no momento da pesagem.

Usando o programa exemplo do componente, configurando para a versão 2.00 do layout, que usa a versão 1.00 do webservice: Basta alterar para a versão 4.00 do layout que tem retorno: Então sugiro que verifique novamente.

Provavelmente você está acessando a URL da versão 1.00 do serviço de recepção de evento, que foi desativada conforme aviso no portal. Deve alterar para a URL da versão 4.00.

O método TACBrTXTClass.LFill é genérico, não se deve levar apenas o Sped Fiscal em consideração, e essa alteração pode causar efeito colateral em algum lugar. Rodando os testes unitários não detectou nenhum problema, mas nunca se sabe. Acho que o mais correto é mover o Trim acima do IF que preenche os caracteres à esquerda, assim mantém-se a finalidade do método, que é preencher os caracteres à esquerda e corrige possíveis erros de input.

Verifique se está configurando a propriedade ACBrNFe1.Configuracoes.Geral.VersaoDF para ve400.

Creio que você estaria escondendo do seu usuário o fato de serem duas notas, e ele seria tributado duas vezes quando estava achando que seria uma só. Se de fato o sistema da prefeitura não permite substituição, você também não deve permitir.

É uma constante declarada em System.Types. Verifique a "unit scope names" nas opções do compilador do seu projeto.

Qual modelo de balança?

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Apenas o destinatário recebe o resumo da nota. Ele precisa fazer a manifestação para obter o XML completo. Os demais interessados não recebem o resumo e sim a nota completa. Por interessados pode ser o transportador com o CNPJ informado na tag correspondente ou terceiros com CPF ou CNPJ informados na tag <autXML>. Se o CNPJ da transportadora não é mencionado na nota fiscal, ela não vai conseguir obter o XML, mesmo que o destinatário faça a manifestação.

Em que campo do layout percebeu isso? Me parece contraditório que o método preencha os caracteres à esquerda e depois remova...

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Não é instantânea a liberação pelo ambiente nacional... Geralmente é preciso aguardar alguns minutos ou horas, em alguns casos até dias, depois da manifestação, pra conseguir obter o XML completo.

Faça teste com xsLibXML2 ou xsMsXml e veja se o erro ainda ocorre.

Certificado A1 ou A3? Acessando pelo PFX ou pelo número de série? Como está a configuração SSLib? Tinha outras aplicações acessando o certificado no momento do erro?

dEmi é que deve ser a hora de conclusão da venda, e não dhCont. Não existe tag dhEnvi... o que existe é a data e hora da autorização, gerado no protocolo de autorização (dhRecebto) e agregado ao XML. Então você vai no XML ter dhCont <= dEmi <= dhRecebto.

dhCont é a data e hora de entrada em contingência, pode ser imediatamente anterior à data de emissão por um problema de conectividade com o webservice, ou por um controle da aplicação em que todas as notas são emitidas em contingência automaticamente, assim a dhCont terá um valor anterior (minutos, horas, dias) a dEmi. dEmi é a data e hora de emissão da nota, ou seja, a data e hora da conclusão da venda, independente se foi emitido em modo normal ou contingência. Você não deve alterar nada no XML ao enviar as NFCe emitidas em contingência, incluindo aí a dEmi e tpEmis, que deve continuar como 9-Offline, então não haverá alteração da chave. Apenas em caso de rejeição no envio pode ser corrigida apenas a informação que gerou a rejeição, gerado novamente o XML e reenviado.