tryideas sistemas

certo, vou abrir chamado com eles

Realizado alguns envios e foram registrados com sucesso, porem 1 registro não foi aprovado, não encontrei o motivo. anexado retorno do WS no arquivo txt, removi os dados dos boletos autorizados, mas os 3 primeiros foram autorizados Rejeição acbr.txt

certo, obrigado pela informação!

Bom dia, previsão será utilizar sicredi V2, sicoob V2 principalmente, teria algum lugar documentando o fluxo referete a cada banco/API?

Fiz alguns testes com o metódo Boleto_ConsultarTitulosPorPeriodo, porém não obtive um retorno de boletos liquidados, apenas permite usar a opção 2 - "Baixados" onde pelo que identifiquei são boletos que foram realizado a baixa do titulo (cancelado). existe alguma forma de consultar quais titulos foram liquidados via WS? vi que é possivel enviar ordens adicionando os titulos e verificando a situação deles pelo metódo Enviar_Boleto, mas ao meu ver para o cliente é muito trabalhoso.

Consegui resolver esse problema, vou investigar mais a fundo para ver se realmente é o caso, mas estava usando em formato x86, mudei a aplicação para x64 e resolveu o problema.

Fiz os testes conforme sugerido, porem sem sucesso!

Boa tarde, realizei a correção do cod. cedente e do Convênio porem o problema ainda persiste. Verifiquei também que ao realizar alguns testes com o Demo que achei uma diferença entre o retorno obtido pelo Demo e pelo meu projeto possui uma diferença, não sei se isso é apenas questão do texto adicionado a exception que acontece. utilizei o mesmo arquivo ini em ambos cenários. que está utilizando no DFVersao=V2 utilizando o Demo consigo fazer a consulta só não estou encontrando o problema no meu projeto.

@Daniel InfoCotidiano Confirmando

@Daniel InfoCotidiano fiz os testes aqui pelo Postman e deu certo, mas na biblioteca ainda continua o erro

Bom dia @Daniel InfoCotidiano Mas está acessando com as mesmas credenciais ? As mesmas utilizadas na API ECOMM? -> Não estava, mas fiz um teste agora utilizando o Token que utilizei na ECOMM no lugar do Secret Client, porem sem sucesso também. Se testar com PostMan ele aceita ? Não encontrei os End Point para realização de teste

Boa tarde, estou tentando realizar a comunicação com a API Versão V2. Porém estou tendo o seguinte Erro no log -> Falha Envio: TBoletoW_Sicredi_APIErro ao gerar token de Autenticação: Código: -E0011 Tamanho de campo invalido. Parametro: token Realizado teste com a outra API ECOMM e esta funcionando normal. coloquei as informações segundo as instruções Tentei na ClientID informar a mesma clientID ao criar aplicativo no site do Sicredi ClientSecret com o clientsecret onde no site é separado pela / já o KeyUser igual ao token após solicitar acesso a ele. tentei também alterar o ClientID para a contaCorrente + Agencia (ambos sem os respectivos dígitos e também com seus respectivos dígitos) alguma sugestão?

Bom, depois de ter postado, acabei encontrando esse post E a solução é essa mesmo, tem que mudar a configuração para imprimir no layout selecionado. Resolvido Obrigado

Olá Daniel. Não ocorre nenhum erro, ele apenas imprime no Layout padrão

Olá a todos Estou tentando imprimir boletos usando o AcbrLib em modo carnê e não estou tendo sucesso. Funcionava no passado mas ao atualizar a DLL, parou de funcionar. Segue arquivo titulos que estou usando em anexo. Testei o mesmo arquivo no Acbr Monitor e a impressão ocorre normalmente. Alguma luz? titulos.ini

Sim, o problema continua. Ao que tudo indica é na receita. Se puderem fazer um teste, basta emitir uma cte em epec e depois tentar transmitir no ambiente normal. Receita do Paraná

Verifiquei aqui os certificados base, inclusive reinstalei alguns pra ter certeza de que não ficasse nenhum alerta no IE com relação a segurança do site. MAS, nada mudou Lembrando que funciona perfeitamente a Emissão de CTe, assinatura, comunicação, etc. O problema é quando a CTe foi emitida em EPEC, ao transmitir para o ambiente normal é necessário gerar o parâmetro &sign no QRCode e é este parâmetro que a validação da Receita está azedando.

Olá a todos Venho já a alguns meses em uma queda de braço com a receita estadual do PR sobre este problema. Antes de dar mais explicações, pra quem quiser entender o que é esse erro o link a seguir explica bem: https://www.oobj.com.br/bc/article/rejeição-855-assinatura-do-qr-code-difere-do-calculado-como-resolver-941.html Conforme a imagem: Pois bem... temos clientes em vários estados e esse problema ocorre APENAS com a Receita Estadual do PR. Inicialmente abrimos chamado e eles verificaram e disseram que o problema era nosso, não deles, visto que eles detectaram outras CTe's já autorizadas assim. E aqui pra ficar claro, o nosso sistema NÃO USA O ACBR. Temos nosso sistema em .NET desenvolvido por nós mesmos. Mas a razão por eu postar isso aqui vou esclarecer em breve. Com a resposta deles, passamos a fazer inúmeros testes, começamos testando o UNINFE que é um projeto open source em .NET para geração e transmissão de documentos fiscais. Neste sistema, o mesmo problema. Em contato com os desenvolvedores os mesmos fizeram testes em outros estados e verificaram também que o problema ocorria apenas no PR. Ficaram de abrir chamado também numa tentativa de pressionar a receita por uma resposta melhor sobre o problema. Passado alguns meses nossos clientes continuam com problema e a lista de clientes nessa situação aumenta. Voltamos a abrir chamado sobre isso mas depois de 3 ou 4 chamados abertos começaram a nos ignorar, fechando chamados onde tivemos que ligar pedindo para reabrirem... só para nos dar a resposta que lá não tem problema nenhum. Feito isso, voltei a fazer testes. Pensei que talvez fosse algo do .NET, instalei o Delphi e fiz um projeto com o AcbrCTe gerando a mesma nota em homologação que eu estava testando. E o Resultado? A mesma coisa: QrCode gerado pelo Acbr: <qrCodCTe> <![CDATA[ http://www.fazenda.pr.gov.br/cte/qrcode?chCTe=41191110969488000113570010000000054039021420&tpAmb=2&sign=R0f3Yt7bHnygFfMr3l3bjNvzaMnEnar5MXIlxx4cqKUjEu9jH6kBxxsFXZkm3Rqouweg8pXawsKk3jLOM8PdhxgcWKgYyh9GuurCZAk4N0Wmq0DSh6v02Yh3CgVmR1AYPO8QSn4V0b2TprEQNDrs22sl3qkRuawPDQRccVMUB5J3pBcpBZ75vSMdBFM3r/rjdBRI6VBnvz3ZwyJWUcJcp2ul6rjS5bs+9dCOU1n2jXw/idCgt0kI8NdG1PBepZuT7J+Xj6qu0okRwFMLduvIisoJwcIJIiNyUUkr4x/zXaMTTImfPJkcASjRkzh9sZI7YQ0AH9+CU+8CBTBM8ZRxhw== ]]> </qrCodCTe> QrCode gerado pelo nosso sistema: <qrCodCTe> http://www.fazenda.pr.gov.br/cte/qrcode?chCTe=41191110969488000113570010000000054039021420&tpAmb=2&sign=R0f3Yt7bHnygFfMr3l3bjNvzaMnEnar5MXIlxx4cqKUjEu9jH6kBxxsFXZkm3Rqouweg8pXawsKk3jLOM8PdhxgcWKgYyh9GuurCZAk4N0Wmq0DSh6v02Yh3CgVmR1AYPO8QSn4V0b2TprEQNDrs22sl3qkRuawPDQRccVMUB5J3pBcpBZ75vSMdBFM3r/rjdBRI6VBnvz3ZwyJWUcJcp2ul6rjS5bs+9dCOU1n2jXw/idCgt0kI8NdG1PBepZuT7J+Xj6qu0okRwFMLduvIisoJwcIJIiNyUUkr4x/zXaMTTImfPJkcASjRkzh9sZI7YQ0AH9+CU+8CBTBM8ZRxhw== </qrCodCTe> O parâmetro Sign é igual em ambos. Confesso que já estou um tanto perdido aqui. Posto aqui até pedindo para que mais colegas testem essa situação e postem suas experiências. E caso identifiquem o mesmo problema, ajudem abrindo chamado na receita estadual para tentarmos pressionar por uma solução se o problema realmente for lá. O número é 0800-411528 Caso alguem estiver usando e funcionando no PR e puder postar seu XML ou ao menos a Chave usada para geração do parâmetro Sign eu agradeço, vai me ajudar a tentar identificar aonde está o problema.

Mesmo problema nos eventos da CTe no PR. Já abrimos ocorrência na SEFAZ

O campo tpEmis deve ser informado com o número 8