Italo Giurizzato Junior

Boa tarde, Esta semana do dia 7 pretendemos liberar uma alteração no componente que acreditamos que vai resolver o problema de codificação. Antes estávamos trabalhando em uma única rotina para resolver o problema de todos os provedores, mas vimos que o caminho não estava correto, mudamos de ideia e agora cada provedor vai ter a sua própria rotina para fazer os devidos ajustes. Como isso, o ajuste promovido no provedor A não vai gerar um efeito colateral nos demais provedores.

Boa tarde Douglas, O meu receio é que com isso o programa exemplo se torne um emissor de NFS-e que por sinal não é o objetivo dele.

Boa tarde Chico, Muito obrigado pela colaboração, mas me diga uma coisa esses espaços reservados para impressão das informações "pintados" de cinza, acredito que algumas transportadoras não vão gostar pois isso ao meu ver vai acarretar um consumo maior de toner, você não acha?

Boa tarde Juliomar, O conteúdo do XML é exatamente igual, independente de usar msXml ou libXml2 o DigestValue e a SignatureValue não deveriam ser exatamente iguais? Ou será que cada um tem o seu método para calcular esses campos?

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

Flavio, Você esta fazendo confusão. Essa mensagem deve ser do envio e não da consulta. Favor realizar um novo teste de envio e anexe os XMLs gerados.

Flavio, Nos XMLs que você anexou se refere a consulta e nela consta a mensagem: "Não existe na base de dados uma NFS-e emitida para o número de RPS informado." Através do programa exemplo essa mensagem não aparece?

Flavio, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-2330

Boa tarde Flavio, Por favor anexe o arquivo ACBrNFSeXServicos.ini com a sua alteração e anexe também o XML de retorno cuja mensagem não esta sendo retornada pelo componente.

Boa tarde Luiz, Enviei para o SVN os arquivos ACBrNFSeXServicos com o provedor e URLs atuais. Vamos aguardar então até o dia 02/03/2022

Boa tarde Daivid, Já enviei para o SVN.

Boa tarde Ramalho, Acredito que o webservice deve ter o seu próprio cadastro e é nele que deve esta errado.

Boa tarde Eduardo, Isso ocorre também com o programa exemplo? Eu não tenho como testar pois não utilizo o Fast Report.

Boa tarde João, Lendo o AJUSTE SINIEF Nº 33, DE 1º DE OUTUBRO DE 2021 e AJUSTE SINIEF 21, DE 10 DE DEZEMBRO DE 2010. Cheguei a conclusão que se trata de um evento que o contratante do serviço deve enviar. Mas para que possamos implementar esse novo evento se faz necessário a publicação de uma Nota Técnica que contem o layout do mesmo. Não me recordo de ter sido publicado alguma Nota Técnica referente a esse evento.

Ramalho, Talvez o problema seja no webservice, o CNPJ/CPF ou a Inscrição Municipal está errada. Me recordo que no webservice a IM estava com formatação e no XML é somente os dígitos, isso fazia com que o Rps fosse rejeitado.

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

Bom dia Ramalho, O CNPJ/CPF do certificado digital é exatamente o mesmo informado no grupo <Prestador> ?

Bom dia Ronald, Você esta usando o Tortoise para baixar os fontes ACBr?

Bom dia, Favor atualizar novamente.

Bom dia Luiz, Que maravilha, avisam nos 47 minutos do segundo tempo.

Bom dia Anadilson, Favor atualizar os fontes, reinstalar o ACBr e faça novos testes.

Bom dia Eduardo, Estudando a implementação do método ImprimirDANFSePDF do Fast Report não encontrei nada que pudesse ele ter esse comportamento, ou seja, gerar o PDF e enviar para impressora. Verifica se na sua aplicação se não esta sendo executado também o método ImprimirDANFSe,

Bom dia a todos, Favor atualizar os fontes, reinstalar o ACBr e realizar testes com a cidade de Sorocaba.

Boa tarde Dercide, O código de verificação esta sendo retornado no campo Protocolo e não em CodVerificacao Não me recordo muito bem o porque dessa mudança.

Eduardo, A não ser que tem alguma implementação diferente para o Fast Report, pois para o Fortes Report ele não imprime somente gera o PDF.