Italo Giurizzato Junior

Boa tarde a todos, Para quem utiliza o componente ACBrCTe e estava com dificuldades de gerar o Hash de Entrega, poderá se utiliza de uma das duas funções que acabam de ser disponibilizadas na unit ACBrDFeUtil. São elas: function CalcularHashDados(const ADados: TStream; AChave: String): string; Devemos utilizar a função acima quando a imagem esta armazenada no banco de dados, neste caso o conteúdo da mesma é passado como Stream no primeiro parâmetro da função, já o segundo é a chave do CT-e. A função retorna uma string com 28 caracteres que devemos atribuir ao campo: infEvento.detEvento.hashEntrega Exemplo: infEvento.detEvento.hashEntrega := CalcularHashDados(xStreamImagem, xChaveCTe); e function CalcularHashArquivo(const APathArquivo: String; AChave: String): string; Devemos utilizar a função acima quando a imagem esta salva em disco, neste caso o primeiro parâmetro da função é o path com o nome do arquivo (imagem) e o segundo é a chave do CT-e. A função retorna a string com 28 caracteres que devemos atribuir ao campo: infEvento.detEvento.hashEntrega Exemplo: infEvento.detEvento.hashEntrega := CalcularHashArquivo(xPathImagem, xChaveCTe);

Boa tarde Adilson, Favor entrar em contato com o provedor e questionar sobre o procedimento de realização de testes. Me parece que existe um CNPJ e senha especifico para o ambiente de homologação.

Boa tarde Flavio, Note que devemos gerar a tag ValorISS quando se tratar de prestação de serviço fora do município. Sendo assim a alteração que você fez não esta correta, pois nunca seria gerado a tag. Fica então a dica: Para o provedor Coplan o valor de ValorISS deve ser zero quando se tratar de prestação de serviço no município e diferente de zero quando for fora do município.

Boa tarde Jean, Estranho, no caso do Ginfes ele retorna o XML da NFS-e e coloca na propriedade XMLNFSe para que você possa salvar o mesmo no Banco de Dados. Mas lembre-se que o XML da NFS-e só é retornado quando é realizado a consulta ao Lote ou a Consulta a NFS-e por RPS ou a Consulta a NFS-e.

Boa tarde Gustavo, Na configuração do componente qual é o valor de: AguardarConsultaRet e IntervaloTentativas ?

Boa tarde a todos, Foi alterado e enviado para o repositório um novo arquivo ACBrNFeServicos.ini Conforme sugestão do Daniel no dia 02/09/2019 devemos alterar esse arquivo e salvar ele na mesma pasta que se encontra o EXE da sua aplicação nas maquinas dos seus clientes. Faça uma atualização de todos os fontes de todas as pastas e abra o arquivo ACBrNFeServicos.ini e veja como ele esta no que se refere a SEFAZ-PA. Ele tem que estar conforme abaixo: [NFe_PA_P] ; A partir do dia 02/09/2019 devemos comentar ou excluir a primeira linha abaixo, e descomentar a próxima linha; ; pois a SEFAZ-PA vai deixar de utilizar a SVAN - SEFAZ-Virtual do Ambiente Nacional e passará para a ; SVRS - SEFAZ-Virtual do Rio Grande do Sul. Usar=NFe_SVAN_P ;Usar=NFe_SVRS_P [NFe_PA_H] ; A partir do dia 02/09/2019 devemos comentar ou excluir a primeira linha abaixo, e descomentar a próxima linha; ; pois a SEFAZ-PA vai deixar de utilizar a SVAN - SEFAZ-Virtual do Ambiente Nacional e passará para a ; SVRS - SEFAZ-Virtual do Rio Grande do Sul. Usar=NFe_SVAN_H ;Usar=NFe_SVRS_H Como deverá ficar no dia 02/09/2019 para ser salvo na mesma pasta do EXE da sua aplicação: [NFe_PA_P] Usar=NFe_SVRS_P [NFe_PA_H] Usar=NFe_SVRS_H Observação: Para aqueles que não tem Clientes contribuintes no Pará não precisam se preocuparem com essas alterações. A partir do dia 02/09/2019 os fontes do repositório estarão com as mudanças e o ACBrMonitorPlus também. Lembrando que o procedimento de copiar o arquivo INI com a alteração para a pasta do EXE da sua aplicação se faz necessário caso não seja possível em tempo hábil disponibilizar uma nova versão EXE em seus clientes.

Boa tarde, Sem novidades.

Boa tarde Cláudio, É bem provável que a consulta pelo QR-Code ainda não esteja 100%. Eu no seu lugar, entraria em contato com a SEFAZ-RS e expunha o problema.

Boa tarde bfBraz, Estamos implementando uma function onde você vai passar a chave e o path com o nome da imagem ou a string da imagem lida do banco de dados e ela vai retornar o Hash pronto para ser atribuído ao campo hashEntrega do evento de Comprovante de Entrega.

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

Boa tarde Flavio, Será que todas as cidades atendidas por esse provedor não se deve gerar a tag em questão? E se alguma dessas cidades deve-se ser enviado? Note que a geração da tag é opcional, ou seja, basta atribuir o valor zero ao campo que ele não será gerado.

Boa tarde Maikon, Muito obrigado pela colaboração, vamos analisar e se estiver tudo OK, vamos enviar para o repositório.

Boa tarde Maikon, Isso foi feito por conta do ambiente de produção ainda exigir a tag e no ambiente de homologação não exigir mais. Enquanto a SEFAZ não remover essa tag do ambiente de produção, você deve atribuir o valor 100 a ela. Por outro lado para realização de testes no ambiente de homologação, você deve atribuir o valor zero a ela.

Boa tarde a todos, Já esta disponível em nossa biblioteca a Nota Técnica 2019/001 versão 1.20 que trata sobre as alterações nas regras de validação. Essa nova versão é uma complementação da anterior que inclusive o seu resumo se encontra aqui. Resumo da NT:  • Remoção da Regra 1C03-10 (A Regra 1C03-10 exigia que Razão Social do emitente informada na tag emit\xNome fosse exatamente igual ao cadastro da SEFAZ, o que se demonstrou problemático). • Correção na Descrição da Regra de Validação N12-90 (Retirada informação de aplicação somente em casos de operação interna). Se CST de ICMS = (20, 30, 40, 41, 50, 70 ou 90): - Verificar se informado o valor do ICMS desonerado (tag:vICMSDeson) e o Motivo da Desoneração (tag: motDesICMS). • Torna facultativas as regras N18-10 e N18-20 (Os tempos de implementação destas regras variam muito entre as diversas Sefaz autorizadoras, por isto a partir da versão 1.20 desta nota técnica estas regras são de aplicação facultativa). N18-10: Se o campo modBCST = “4” Margem Valor Agregado, obrigatório o preenchimento do campo pMVAST. N18-20: Se o campo modBCST <> “4” Margem Valor Agregado, não deverá ser preenchido o campo pMVAST . • Criado novo Valor para o Campo N18 (A tag modBCST passa a aceitar a opção “6=Valor da Operação”). Datas previstas para entrada em vigor: 26/08/2019 - Ambiente de Homologação; 02/09/2019 - Ambiente de Produção. Alterações no componente: Criado o valor dbisValordaOperacao, para o campo modBCST. Alterações na aplicação do desenvolvedor: Prever o uso do novo valor para os CST 10 e 30. Para quem utiliza o ACBrMonitor, basta atribuir o valor 6 ao campo modBCST para os CST 10 e 30 quando for o caso. Foi publicada uma nova tabela: cBenef x CST atualizada até 19/08/2019, a qual pode ser baixada aqui, além dos novos schemas para atender o novo valor do modBCST. Até o final desta semana estaremos disponibilizando os novos schemas para que semana que vem, vocês possam iniciar os testes em ambiente de homologação.

Bom dia Sérgio, Acredito que a sua aplicação esta gerando um novo XML, isso não se faz necessário. O XML para ter validade jurídica ele precisa estar assinado e com o protocolo de autorização. O cancelamento é um evento, como o próprio nome diz é algo eventual que pode ou não ocorrer. Sendo assim existe um segundo XML chamado *-procEventoMDFe.xml que contem o pedido de cancelamento (se for o evento de cancelamento), a assinatura digital mais o protocolo que acusa o evento foi aceito pela SEFAZ. Em hipótese nenhum devemos trocar o Protocolo de Autorização por outro no XML do MDF-e.

Bom dia Wagner, Mudança no conteúdo da carga ou do caminhão, se faz necessário o encerramento do MDF-e e a emissão de um novo. Talvez o sistema utilizado por essa outra empresa, faz as coisas de forma mais automatizada, ou seja, ao escolher a opção de troca de caminhão, ela deve solicitar os dados do novo caminhão e o numero do MDF-e cujo caminhão vai ser trocado, a partir desse ponto o sistema pega todos os dados desse MDF-e, envia o evento de encerramento, gerada e envia um novo com os dados do novo caminhão.

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

Bom dia Ricardo, Analisando o código notei que esta previsto a leitura do retorno da consulta. Será necessário "debugar" para saber o local exato do erro.

Bom dia Marcio, Esse provedor na verdade não esta implementado 100% pelo simples fato de usar uma forma de assinar totalmente diferente dos demais.

Boa noite Sérgio, Mas esse XML que você anexou não contem o protocolo de autorização, logo o componente vai imprimir no DAMDFE a mensagem que o mesmo não foi enviado para a SEFAZ.

Boa tarde Adileine, Pelo que entendi para efetuar o cancelamento da averbação em vez de você enviar o XML do CT-e assinado e com o protocolo de autorização, você deve enviar o XML *-procEventoCTe.xml referente ao cancelamento do CT-e. O arquivo *-procEventoCTe.xml contem o pedido de cancelamento assinado e o protocolo da SEFAZ que homologa o cancelamento.

Bom dia Dirlenio, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia Paulo, Como assim, "eu salvo mas as vezes pode não salvar" ? Se você esta usando o banco de dados que hora salva os dados, hora não salva, você não acha que esta na hora de mudar para um banco de dados mais confiável? Ainda não entendi a dificuldade de usar a função que criamos, que gera o código da forma recomendada pela SEFAZ e o valida, garantido desta forma que a sua nota vai ser aceita pela SEFAZ. Após gerar o código, salvar o mesmo com os demais dados da nota. Obviamente que para isso será necessário acrescentar mais um campo na tabela para armazenar o código. Eu acredito que isso não deva ser uma tarefa extremamente complicada, ou estou enganado? A minha aplicação de emissão de NF-e foi escrita em 2008, ao ler o manual da NF-e mais precisamente as paginas que se refere o layout da NF-e e encontrei isso: Note que o tamanho do código naquela época era de 9 dígitos, depois foi alterado para 8 pois acrescentaram na chave entre o numero e o código o tipo de emissão. Portanto, não se trata de frescura nossa, não é algo novo que a SEFAZ inventou agora para complicar a nossa vida. A recomendação de gerar o código de forma aleatória já faz anos e põe anos nisso. Eu entendi o recado da SEFAZ escrito na última coluna e segui a recomendação. Inclusive no meu artigo: Código Numerico inválido chave não gerada mostro como eu gerava o código na minha aplicação e a alteração que fiz para passar a usar a função que foi criada. Para finalizar, a aplicação é sua faça da forma que achar melhor, motivos para gerar o código de forma aleatória existem de sobra.