Italo Giurizzato Junior

Bom dia Camilo, Ocorreu a troca do executável? Ou de um dia para outro começou a retornar esse erro? Se não ocorreu a troca do executável, favor entrar em contato com o provedor para saber qual é o motivo do lote não ter sido processado.

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

Boa tarde Adilson, Se tratando das URLs de homologação e de produção no arquivo Pronimv2.ini agora tem somente isso: [URL_P] ; Soledade/RS RecepcaoLoteRPS_4320800=http://186.237.127.134/nfsews/services.svc ; Demais Cidades RecepcaoLoteRPS=%NomeURL_P%/nfse.portal.integracao/services.svc [URL_H] ; Soledade/RS RecepcaoLoteRPS_4320800= ; Demais Cidades RecepcaoLoteRPS=%NomeURL_H%/nfse.portal.integracao.teste/services.svc Como você pode ver se a cidade não for Soledade/RS as demais até agora as URLs são padronizadas, com isso foi possível a utilização das variáveis NomeURL_P e NomeURL_H Apague os arquivos que contem uma bolinha vermelha no ícone e atualize novamente.

Bom dia Costa, Chegou a fazer testes usando o programa exemplo?

Bom dia Lucas, Eu não tenho nenhuma aplicação que emite GNRE, mas vamos ver se eu consigo lhe ajudar. Primeiro vamos tentar entender essa mensagem de erro. "O Documento de Origem informado não é usado pela Receita informada na UF favorecida! O "Documento de Origem" que a mensagem se refere, acredito ser a chave da NF-e informada na tag <valor> do grupo <campoExtra> A "Receita Informada" que a mensagem se refere, acredito ser o código informado na tag <receita> do grupo <item> Por fim a "UF favorecida", acredito ser a UF informada na tag <ufFavorecida> Como não acusou que a UF favorecida esta errada e nem o código da Receita, chego a conclusão que ao informar esse tipo de receita não devemos informar a chave da nota. Como disse logo no inicio não tenho nenhuma aplicação que emite GNRE e não conheço muito sobre essa Guia. Posso ter escrito besteira, vamos aguardar se mais alguém do fórum com mais conhecimento possa lhe ajudar.

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

Bom dia a todos, Robson, você ainda esta configurando o componente com o libCapicom? Porque não muda para libWinCrypt?

Boa tarde Mauricio, Atualize os fontes. Não precisa mais alterar o arquivo Pronimv2.ini somente o Cidades.ini Que por sinal já fiz as devidas alterações.

Boa tarde Lucas, Notei que no seu XML esta faltando a IE do emitente.

Boa tarde Marcos, Como assim você comentou a unit que esta faltando? Se após a atualização você teve algum erro é porque você não atualizou todos os fontes de todas as pastas. E também não reinstalou a suíte ACBr usando o ACBrInstall_Trunk2 com a opção apagar arquivos antigos marcada. E também não compilou a sua aplicação com a opção Build.

Boa tarde Ana, Eu não tenho nenhuma aplicação que envia os eventos do e-Social. Mas vamos a primeira rejeição: Verifique os dados informados pois apresentam divergência entre CPF e NIS, ou o NIS não e o mesmo que foi informado em sua admissão/inicio de TSVE ou em sua ultima alteração cadastral. A mensagem diz que o NIS não se refere ao CPF informado e pede para verificar se o NIS é o mesmo informado na admissão ou na ultima alteração de cadastro. Você chegou a verificar tudo isso?

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

Boa tarde Caneschi, Curiosidade, o que os contadores vão fazer com o DAMDFE impresso? Eles são loucos, o Manifesto não tem valor contábil, só serve para facilitar a fiscalização em postos rodoviários como por exemplo os que existem na fronteira entre os Estados. Acredito que ainda vai levar umas 10 semanas santas até esses contadores entenderem que o DANFE, DACTE, DAMDFE não tem valor nenhum, hoje documento fiscal propriamente dito é o XML desde esteja assinado e com o protocolo de autorização gerado pela SEFAZ-Autorizadora, conforme consta na legislação. O componente responsável pela impressão de DAMDFE possui uma propriedade de configuração chamada Encerrado. Se você atribuir o valor True e mandar imprimir ou gerar o PDF, vai constar uma tarja com o texto MDF-e Encerrado. De forma semelhante temos a propriedade chamada Cancelada, caso o seu valor seja True vai constar a tarja MDF-e Cancelado.

Boa tarde, Se não me falha a memória a impressão dessa informação foi removida, ou seja, não esta sendo mais impressão, pois no novo layout do DAMDFE que contem o QR-Code não esta previsto a impressão das informações referentes ao seguro. Outra coisa, é possível informar até "n" números de averbações com até 40 caracteres cada um, como que ficaria o layout do DAMDFE para suportar a impressão.

Boa tarde Adilson, Muito obrigado pela colaboração. Observação: os seus fontes estão desatualizados em especial os arquivos INI utilizados pelo componente ACBrNFSe.

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

Bom dia Marcus, Você emitindo um BP-e para uma viagem dentro do município?

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

Bom dia Werberth, Se você não informar para qual cidade ou provedor esta enviando o pedido de substituição de NFS-e, não tenho como lhe ajudar.

Bom dia Ignácio, Você esta com todos os fontes atualizados? Se sim, reinstalou a suíte ACBr? Se sim, chegou a emitir uma NFC-e (por exemplo) informando o CPF do destinatário? Se a resposta é não para as minhas perguntas acima, com certeza as dezenas não vão ser impressas nos DANFE da NF-e e NFC-e.

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

Desculpe, errei o seu nome.

Bom dia Ana, Você diz, colocar o nome do município a direita da UF de descarregamento? A resposta é: Não. O motivo é simples, o mesmo MDF-e pode ter mais de um município de descarregamento dentro da mesma UF. Exemplo: O caminhão sai de Araraquara/SP com carga a ser descarregada em São Carlos/SP, Limeira/SP, Campinas/SP e São Paulo/SP Da forma que esta hoje, no MDF-e vai imprimir a cidade de descarregamento (São Carlos/SP) e abaixo as chaves dos CT-e referente a carga que será descarregada nessa cidade. Abaixo será impresso a cidade: Limeira/SP em seguida as chaves dos CT-e referente a carga a ser descarregada nessa cidade. E assim por diante. Da forma que esta hoje fica muito claro saber pela chave do CT-e qual carga será descarrega e em qual cidade. Não sei se ficou claro.

Bom dia Soares, No caso do CT-e, a SEFAZ-MG se utiliza da SVC-SP - SEFAZ Virtual de Contingência de SP, quando o CT-e é enviado em contingência. A SVC-SP a principio esperava encontrar no XML o endereço de consulta de SP, mas depois mudou, ou seja, no XML deve sempre constar o endereço de consulta de MG. Com certeza os seus fontes estão desatualizados, portanto esta gerando o endereço de consulta de SP, dai a rejeição apresentada na imagem que você anexou. Favor atualizar todos os fontes de todas as pastas. Reinstale a suíte ACBr usando o ACBrInstall_Trunk2 com a opção apagar arquivos antigos marcada. Compile a sua aplicação com a opção Build. Faça novos testes.

Bom dia, A rejeição referente a duplicidade só ocorre quando é enviado um outro documento com o mesmo numero e serie, ou quando se envia o mesmo documento pela segunda vez. O que deve ter ocorrido: 1. Foi enviado o CT-e de numero 476 serie 1; 2. Ocorreu algum erro, do tipo timeout; 3. O usuário enviou novamente o mesmo CT-e; Como a sua aplicação gera o XML antes do envio e não utiliza o mesmo cCT definido no envio anterior ocorreu a rejeição de duplicidade com diferença de chave. Vamos a um exemplo: Primeiro envio: CT-e de numero 476, série 1, cCT igual a 13 Segundo envio: CT-e de numero 476, série 1, cCT igual a 14 Se no primeiro envio apesar do erro de timeout a SEFAZ recebeu o CT-e e o autorizou, ao enviar pela segunda vez o mesmo CT-e a SEFAZ vai rejeitar pois já existe o CT-e de numero 476 e série 1, como o cCT é diferente vai acusar que a rejeição por duplicidade com diferente de chave, entenda diferença de chave como sendo cCT diferentes. Como eliminar esse tipo de rejeição: 1. Ao salvar no banco de dados as informações referente ao CT-e, gere e armazene também junto com os demais dados o cCT (Código do Conhecimento de Transporte). Esse código deve ser aleatório e temos uma função para isso: GerarCodigoDFe. Devemos passar como parâmetro a essa função o numero do Conhecimento de Transporte - nCT. 2. Ao alimentar o componente com os dados do CT-e, devemos ler do banco de dados o campo que contem o código e atribuir a cCT. Desta forma a chave que o componente gera será sempre igual, portanto com isso eliminamos a rejeição por diferença de chave. 3. Se ao enviar ocorrer erro, jamais envia novamente, pelo simples fato de não sabermos se o erro de conexão ocorreu durante o envio ou durante o retorno. O correto neste caso é, carregar o XML do CT-e (que ocorreu erro de conexão) através do método LoadFromFile e em seguida executar o método Consultar. Se o erro ocorreu no retorno, ao consultar novamente e se essa consultar for bem sucedida o XML do CT-e será atualizado com o protocolo de autorização caso ele tenha sido autorizado. Por outro lado se o erro ocorreu durante o envio a SEFAZ vai retornar uma rejeição acusando que o CT-e não existe na base de dados, ai sim devemos enviar novamente. Desta forma eliminamos de vez o problema de rejeição por duplicidade. Espero ter ajudado.