Italo Giurizzato Junior

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 Luiz, Como eu disse, alguns contadores realizam a manifestação das notas para obter o XML das mesmas e com isso realizar a escrita fiscal e contábil. No meu entendimento isso esta errado, pois muitos contadores utilizam aplicações que envia o evento de Manifestação (Ciência da Operação) de forma indiscriminada. Como o contador sabe se o seu cliente comprou ou não de um determinada empresa?

Bom dia Weslei, Favor atualizar os fontes e faça um novo teste de cancelamento.

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.

Boa noite Luiz, A Manifestação do Destinatário é um evento (existe 4 tipos de eventos) que deve ser enviado pelo destinatário da mercadoria. Agora se o seu cliente que é destinatário da mercadoria esta baixando o XML completo da nota sem enviar o evento de Manifestação do destinatário, é preciso verificar se o CNPJ dele não esta no grupo autXML. Até onde sei a SEFAZ deveria rejeitar uma nota cujo CNPJ ou CPF do destinatário conste também no grupo autoXML. Se não consta, concluo que alguém esta manifestando as notas emitidas contra o CNPJ do seu cliente. E esse alguém pode ser o contador.

Boa noite Reinaldo, Concordo plenamente com você.

Boa noite, É impressão minha ou os valores de prestador e nota estão criptografados? Ai o bicho pega.

Boa tarde Weslei, Ao consultar o Lote você esta informando o numero do mesmo?

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.

Bom dia Ricardo, Favor anexar os XMLs gerado a realizar a consulta.

Bom dia Celso, Favor atualizar todos os fontes de todas as pastas, reinstale a suíte ACBr e faça novos testes. O seu arquivo Cidades.ini esta bem desatualizado, esta com apenas 56 kbytes sendo que o que esta no repositório tem 85 kbytes.

Maikon, Vou enviar essa alteração para o repositório.

Bom dia Reinando, Esse problema já foi observado, a questão é o seguinte: Realmente há necessidade de imprimir essas informações no DAMDFE? Visto que no layout que consta no manual do MDF-e referente ao Documento auxiliar não consta a impressão dessa informação. Um outro usuário do fórum até fez uma alteração no DAMDFE visando permitir a impressão dos 40 dígitos do numero da averbação, mas por outro lado limitaria a impressão de no máximo 2 averbações. No MDF-e posso relacionar até 10 mil CT-e (Transportadora) ou até 10 mil NF-e (Transportador de carga própria). Se temos que averbar cada um desses documentos (CT-e ou NF-e), supondo um MDF-e com apenas 50 documentos, quantas folhas o DAMDFE vai precisar ter para imprimir as informações referente ao seguro? Até onde sei o DAMDFE é uma representação gráfica, ou seja, em papel do que esta no XML, mas não se faz necessário imprimir tudo o que esta no XML, devemos no mínimo imprimir o que consta no layout apresentado no manual como exemplo.