Painel de líderes

Bom dia Roger, Muito obrigado pela colaboração, vou analisar e estando tudo OK vou enviar para o repositório.

Boa tarde. Ocorreu mudança na URL para integração da NFSe na cidade de Ijuí-RS. Conforme notícia divulgada no site do município: https://www.ijui.rs.gov.br/paginapref/manual_de_orientacao_dos_procedimentos_administrativos/nota_fiscal_de_servico_eletronica Segue em anexo arquivo Pronim.ini com a alteração. Já foi testado em um cliente e funcionou corretamente. Pronim.ini

show é isso ai. como diz o Daniel use a força, leia o código . os fontes estão todos ai pra ser explorado

Alteração já se encontra no SVN.

chegou a olhar os exemplos?

Pessoal eu fiz um procedimento segundo o @marcioereno e deu certo : Ao tentar enviar caso não retorne a chave de acesso da tentativa no campo da chcte do CTE, verificar no XML a chave da tentativa retornada e após inserir no campo (no meu caso fiz via banco de dados) da xchcte de acesso da numeração que esta sendo enviada e consultar esta chave. Caso o CT-e esteja correto vai buscar os dados do envio.

@RicardoVoigt consegui resolver o problema: Tenho que carregar o xml após o envio. Codigo anterior: ACBrNFe1.EnviarEvento(StrToInt(idLote)); ACBrNFe1.ImprimirEvento; Código novo: ACBrNFe1.EnviarEvento(StrToInt(idLote)); ACBrNFe1.EventoNFe.Evento.Clear; ACBrNFe1.EventoNFe.LerXML(ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.NomeArquivo) ; ACBrNFe1.ImprimirEvento;

A chave de acesso é gerada baseada nos valores informados para os campos que a compõe. - UF do emitente - Mês e ano da emissão - CNPJ do emitente - Modelo - Série - Número - Tipo de emissão (tpEmis) - Código numérico (cNF) - Dígito verificador. Então, exceto para o dígito que é calculado, basta informar o valor de cada um desses campos individualmente que você terá a mesma chave de acesso.

https://svn.code.sf.net/p/acbr/code/trunk2/Fontes/ACBrDFe/ACBrNFe/ACBrNFeServicos.ini

Boa tarde! Estou criando um novo tópico para ficar mais fácil de explicar as alterações que foram realizadas na Unit: ACBrBancoSafra.pas. Estou homologando os boletos e o arquivo de remessa, e me deparei com alguns erros no código de barras e consequentemente na linha digitável. Os detalhes técnicos do problema podem ser visto nesse outro tópico: Mas enfim, vamos as alterações que realizei: Na função: MontarCodigoBarras, adicionei um trim() nos campos de: "Cedente.AgenciaDigito" e "Cedente.Conta", o mesmo estavam ficando com um espaço em branco, ocasionando a geração do código de barras com um dígito a menos. Na função: MontarCampoNossoNumero(), foi removido o: " '-' + CalcularDigitoVerificador(ACBrTitulo)", ficando apenas o NossoNumero, também foi alterado a quantidade de caracteres, que estavam setados como 8, porém o nosso numero é composto por 9 caracteres. Na função: MontarCodigoBarras, foi alterarado a linha que compõem o código de barras de: para: pois a mesma estava sendo executada na funcao: CalcularDigitoCodigoBarras() , sendo passado como parâmetro 44 dígitos, porém o Banco Safra utiliza apenas 43 dígitos para calcular dígito do código de barras. Também foi adicionado um espaço entre a barra que divide o "número da agência" e o "código do beneficiário". Essa alteração reflitirá apenas a nível de impressão! Alterado a logo do Banco Safra. (A logo que possui no ACBr está desatualizada) A nível de impressão do boleto: o nosso número deve ser apenas 9 caracteres sem o dígito verificador. correção 2, Agência: Header Lote e Segmento P, foram alterados para o preenchimento dos zeros serem a direita. Também estou anexando uma planilha do excel onde eu reproduzi a função que o ACBr estava calculando o dígito verificador, para confrontar com a forma que o Banco Safra gerava. Pois o ACBr estava gerando errado. Para comprovar, basta analisar o print que o banco me enviou, explicando como é gerando o código de barras! O banco utilizou 43 dígitos para calcular e o ACBr 44, desta forma ocasionando divergência no dígito. 422.bmp ACBrBancoSafra.pas PLANILHA DE ANALISE DE BOLETO BANCÁRIO.xlsx

- Você informa os dados do emitente, a cidade com código do IBGE da mesma. - O componente procura no arquivo Cidades.ini essa cidade e verifica qual provedor está associado a mesma.

Boa tarde Danilo, Não detenho conhecimento amplo no que diz respeito a assinatura digital, mas deve ser alguma incompatibilidade com o certificado.

Para NFCe o MA usa a SVRS: https://sistemas1.sefaz.ma.gov.br/portalsefaz/jsp/pagina/pagina.jsf?codigo=3876

boa tarde eu tentei aqui pela chave e realmente foi , obrigado

Os caras se superam... SEFAZ-PR é um show de incapacidade.

Estou com o mesmo problema e a solução temporária encontrada foi fazer a "Recuperação do XML" e a atualização do mesmo na base de dados. Neste caso retorna com a autorização e ai podemos dar continuidade ao processo.

Concordo contigo, agora, o problema em questão é a situação de não obter o retorno durante a transmissão devido a essa instabilidade da Sefaz, o CTe foi transmitido só não obtém o retorno, mas referente aos erros de preenchimento, imagino que você pode tentar validar o xml no site da própria Sefaz para ver se está com algum preenchimento indevido.

OK deu certo quando mudei. Engraçado pq estava passando nota normal

Bom dia Danilo, Você esta com todos os fontes de todas as pastas atualizados? Se sim, reinstalou a suíte ACBr usando o ACBrIntall_Trunk2? Configurou o componente para qual versão (1.00 ou 2.00)? Se sim, chegou a fazer testes utilizando o libWinCrypt?

Me parece que o problema não é apenas com a SEFAZ-PA, mas com a SVRS em si. Detalhe que o problema afeta apenas os webservice de consulta de retorno de autorização e consulta de recibo. Então o envio em modo síncrono deve funcionar. Quem puder faça o teste e favor reporte. @igmaster2000

https://www.sefaz.rs.gov.br/NFE/NFE-VAL.aspx Faltou acrescentar os dados das adições.

BigWiings pode ser isso meu amigo, vou testar.

Seu FastReport é versão Embarcadero? Se sim, pode ser esse o problema. Essa versão do Fast não tem suporte a scripts e é incompatível com os arquivos do repositório. Você pode: - Usar os arquivo *BASIC*.fr3 do repositório, da pasta Obsoletos. Atenção que esses arquivos não estão mais sendo mantidos. - Usar uma versão comercial, Standard ou acima, do FastReport. - Usar os componentes DANFE para FortesReport.

Qual fr3? testou com outros da pasta?

Boa tarde, a melhor solução é utilizar o MFe pois não depende mais do aplicativo Integrador Fiscal do CE: Mas se for utilizar NFCe precisa do Integrador veja esse tópico: No Componente precisa vincular o componente na propriedade "Integrador"

José, Então voce descobriu o problema. Na minha chamada eu incluo o diretório e o monitor também inclui. Vou tirar o nome da pasta e testar Te aviso Abs

Boa tarde @Italo Jurisato Junior Seguem arquivos para análise. Nossa alterações: - A alteração no arquivo ACBrDFeHttpWinApi.pas não tem a ver diretamente com a implementação do novo provedor. Simplesmente facilitou no processo de desenvolvimento/debug. - Criamos um novo provedor que chamamos proDSFSJC (já que esta implementação da DSF é exclusiva pra São José dos Campos). Para tanto alteramos o arquivo Cidades.ini para que o arquivo de inicialização de SJC passe a ser o DSFSJC.ini. - Criamos o arquivo DSFSJC.ini baseado no arquivo GINFES.ini e nele alteramos os namespaces, as urls de acesso e as configurações necessárias. A mais curiosa é a inclusão de uma seção CDATA na montagem dos xmls de envio. Esta seção é necessária e foi incluída por indicação do próprio pessoal da DSF (sem ela o arquivo não é entendido pelo webservice deles). Eu não sei exatamente o que ela faz, talvez alguém com mais experiência nisso possa esclarecer este ponto. - Aí então fizemos as alterações necessárias nos próprios fontes do ACBr (criamos o enumerado proDSFSJC, e os devidos tratamentos de envios e respostas). Algumas considerações/explicações: - Nós utilizamos os seguintes métodos (somente estes foram testados e validados) : * RecepcionarLoteRpsV3 * ConsultarSituacaoLoteRpsV3 * ConsultarLoteRpsV3 * ConsultarNfsePorRpsV3 * CancelarNfseEnvio - A implementação da DSF foi bem curiosa. Pelo que entendi a ideia era causar o mínimo impacto nas aplicações dos contribuintes e para isso eles mantiveram a estrutura de xmls do GINFES. Mas a lógica de implementação e o conteúdo dos arquivos de resultados (e às vezes mesmo a estrutura deles) não são os mesmos. Exemplos: * O retorno do método ConsultarLoteRpsV3 não traz a identificação de cada um dos rps no lote. Ou seja, não é possível saber a situação de cada um deles após o envio do lote neste método. * Para saber da situação de uma determinada nota, deve-se chamar o método ConsultarSituacaoLoteRpsV3 para garantir que o lote foi processado e em seguida chamar ConsultarNfsePorRpsV3 para saber da situação da nota em si. * Apesar da estrutura do xml de envio do método CancelarNfseEnvio ser igual à do Ginfes, o arquivo de retorno é totalmente diferente e exigiu uma implementação nova de tratamento de retorno nos fontes do ACBr. Além dos arquivos fonte alterados e dos novos arquivos .ini estou anexando os arquivos .xds que nos foram repassados pela DSF. Fico à disposição para quaisquer dúvidas. ACBrDFeHttpWinApi.pas ACBrNFSeDANFSeFR.pas ACBrNFSeWebServices.pas Cidades.ini DSFSJC.ini nfse.xsd pnfsCancNfseResposta.pas pnfsConversao.pas pnfsNFSeG.pas pnfsNFSeW_ABRASFv1.pas xmldsig-core-schema20020212.xsd

Boa tarde Adilson, No arquivo INI do provedor Fiorilli consta que a versão é 2.01 do layout da ABRASF, favor verificar junto ao provedor, qual é a versão para essa cidade. Existem as versões: 2.02 e 2.03

Boa tarde Pedro, Muito obrigado pela colaboração, já enviei para o repositório.

Acabei de ler outro topico https://www.projetoacbr.com.br/forum/applications/core/interface/file/attachment.php?id=63933 Vou atualizar com esse arquivo pra testar e posto se deu certo ou nao . Obrigado .

Deu Certo, coloquei pra -04:00 Obrigado @BigWings!

Boa tarde. Estes dois últimos problemas parecem ser problemas no cadastro do prestador.. Att,

blz, muito obrigado deu certo.

Enviei correção para o repositório, rev. 17549. Favor atualizar os fontes e testar novamente.

Não entendi, ou você atualiza os fontes do ACBr ou não... Se estiver com os fontes antigos o grupo pode não ser gerado quando pICMSInterPart = 0, isso foi alterado quando a tag foi removida. Então atualize os fontes do ACBr e tente novamente.

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

José esta resolvido , o problema era o arquivo pfx do cliente . De forma obrigado pela ajuda .

Correto, quando um titulo "normal" é descontado, vem pro cobrança um instrução tipo "baixa por desconto". E no empréstimo este mesmo titulo em uma instrução de entrada e depois segue seu ciclo pelo "empréstimo" Entendi, gostei da forma de desenvolvimento que você sugeriu. Eu posso desenvolver isto aqui com base no Itaú, o qual tenho o manual, e possuo meios de testar principalmente os retornos deste tipo de serviço [emprestimo] novo.

Enviei correção para o repositório, rev. 17533. A forma que encontrei foi usando a var. TotalPages e ativando o DoublePass, assim como é feito no DANFE. Favor atualize os fontes e teste com o fr3 do repositório.

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

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

RESOLVIDO Tratava-se do código do município... O exemplo diz.... // Para o provedor ISS.NET em ambiente de Homologação // o Codigo do Municipio tem que ser '999' desta forma o acbr acabava selecionando o provedor incorreto..

Boa noite Italo, Era isso mesmo, apos alterar o código da aplicação para não gerar o XML novamente, e carregar o XML de autorização a tarja de cancelamento foi atribuída normalmente. Muito Obrigado.

Certo, obrigado pelo esclarecimento @BigWings

Para NFCe o PA já usa a SVRS, então será alterada apenas NFe.

pessoal resolvi aqui mudando a configuração do componente acbrnfe1 SSLXMLSIGNLIB =XsMsXml

Bom dia, tive esse problema no demo da NF-e, só consegui compilar deletando o .res No meu caso, como queria apenas validar alguns dados pelo demo, resolveu!

Você vai usar o campo "Titulo.DataProtesto", para os títulos que você quer protestar, se não quiser basta não preencher esse campo.