Pesquisar na Comunidade

Fala pessoal ! Venho comunicar uma alteração de endpoint da API para testes do Santander V1 , devido o ambiente Sandbox não ser fiel ao ambiente real (de produção) conforme instrução do próprio Santander, optamos por alterar para o uso do ambiente de HOMOLOGAÇÃO, o qual alteramos o método de envio para que seja enviado para endpoints diferentes para que possamos unificar as respostas necessária para retorno correto. Como estava Estávamos utilizando o endpoint SandBox para testes: C_URL_HOM = 'https://trust-sandbox.api.santander.com.br/collection_bill_management/v2'; C_URL_OAUTH_HOM = 'https://trust-sandbox.api.santander.com.br/auth/oauth/v2/token'; Infelizmente estava retornando dados incompletos nas consultas, quando o usuário relatou ao suporte do banco, ele nos orientou a utilizarmos o endpont de Homologação: Para se integrar com o ambiente de homologação, precisa entrar em contato com seu especialista Cash. Como ficou Quando você realiza a consulta, nós vamos realizar 3 consultas diferentes. Isso porque a API do Santander, infelizmente não está devolvendo todas informações necessárias em apenas uma consulta. (que vou explicar abaixo). Lembrando que você vai realizar apenas uma consulta e todo este processo de consultas diferentes será realizada em backend pela solução ACBrBoleto, o qual vai te devolver todas as consultas em uma reposta unificada. Você não precisa alterar nada nos seus fontes, apenas solicitar credenciais para o ambiente de homologação com o seu especialista Cash. O endpoint passou de SandBox para Homologação. Então a partir de agora, estamos utilizando como padrão este novo endpoint para testes. C_URL_HOM = 'https://trust-open-h.api.santander.com.br/collection_bill_management/v2'; C_URL_OAUTH_HOM = 'https://trust-open-h.api.santander.com.br/auth/oauth/v2/token'; Infelizmente a consulta no novo endpoint não devolve todos os dados em uma unica consulta. Na consulta padrão, não estava devolvendo corretamente os juros ou valor pago com juros. E foi necessário utilizar outra consulta conforme sugestão abaixo: Infelizmente a consulta acima, que devolve informações sobre o juros, não devolve a data credito ou data baixa. Após reportar que a consulta NN não devolve as datas credito/baixa Foi sugerido utilizar a primeira consulta que não volta juros. Em resumo para contornar a situação, estamos realizando consultas em 2 ou 3 formas diferentes para que possamos unificar os dados necessários para uso enquanto o banco não corrige as consultas. Sendo assim, atenção ! 1. só existe consulta detalhada! (não existe consulta em lista) Para a consulta devolver informações de boletos e do pix (caso exista) antes de realizar a consulta marque o indicadorPix como true; Se estiver marcado o Indicadorpix como true ele vai realizar uma consulta do boleto bankslip, caso esteja liquidado/baixado vai realizar mais 2 consultas por NN (nosso numero) para pegar o juros e Setlement para pegar as datas de credito/baixa. Se não o indicadorPix for false, vamos consultar se ele está liquidado/baixado vai realizar consulta por NN (nosso numero) para pegar o juros e Setlement para pegar as datas de credito/baixa. Como o Santander difere de outros endpoints que realizamos apenas uma consulta, pode ser que fique lento alguns segundos.. ja que precisamos enviar a primeira consulta, aguardar para disparar a segunda consulta aguardar novamente e disparar terceira e unificar as respostas. Links de referência: Usar Homologação e não sandbox: Utilizar consultas NN e Settlement:

Boa tarde comunidade ! Em 4 de março, tínhamos postado aqui no fórum atualizações de endpoint p testes em homologação. mas hoje foi removido até dos manuais Santader este endpoint. (link do post anterior) O usuário @Leandro Coelho nos reportou que o SANTANDER removeu os endpoint que estávamos utilizando e voltou para SandBox. Então hoje fizemos atualização destes endpoints.: {URL Produção} C_URL = 'https://trust-open.api.santander.com.br/collection_bill_management/v2'; C_URL_OAUTH_PROD = 'https://trust-open.api.santander.com.br/auth/oauth/v2/token'; {URL Homologação open-h removido no manual 2.6 do banco santander}: //C_URL_HOM = 'https://trust-open-h.api.santander.com.br/collection_bill_management/v2'; //C_URL_OAUTH_HOM = 'https://trust-open-h.api.santander.com.br/auth/oauth/v2/token'; {URL Sandbox - Adicionado} C_URL_HOM = 'https://trust-sandbox.api.santander.com.br/collection_bill_management/v2'; C_URL_OAUTH_HOM = 'https://trust-sandbox.api.santander.com.br/auth/oauth/v2/token'; E-mails com orientação do banco, post original clique aqui primeiro email em 13/08/2024: Segundo email confirmado em 21/08/2024 Obrigado @Leandro Coelho por reportar! Commit: 35189

Olá pessoal! Gostaria de saber que estrategias posso adotar para esse meu caso! A minha situação é a seguinte: Não utilizamos diretamente os fontes do ACBr, mas importamos para um outro repositório GIT. Fazemos isso sempre que é necessário. A frequência varia. A última vez que isso foi feito foi no mês de Janeiro/2018. Agora recentemente foi preciso mais uma vez fazer isso devido a determinadas alterações que foram feitas. Fiz a importação.... Consegui... Só que teve várias alterações nos fontes do ACBr, como: NF-e, CT-e, NFS-e, Boletos, SPED, MDF-e, etc. (E isso é muito bom!) Mas, terei que testar tudo isso! Isso requer muito tempo, trabalho e mesmo fazendo isso poderá ocorrer problemas com o cliente por que existem muitas possibilidades, como numa NF-e, por exemplo. Nesse caso, acredito que não tenho outra alternativa a não ser testar tudo! Mas fico pensando não só no agora, mas sim no futuro. Pode ser que eu precise atualizar novamente daqui a pouco tempo. Daí terei que testar "tudo" de novo! Até pensei em atualizar os fontes do ACBr com uma frequência menor. Mas dependendo o que foi alterado terei que testar tudo do mesmo jeito (pelo menos é o que eu penso). Então, alguém tem alguma sugestão que possa pelo menos facilitar esse trabalho? Qual a melhor frequência de atualização dos fontes ACBr? Alguma dica sobre como posso fazer esses testes? Alguém passa ou já passou por esse dilema? Porque creio que não sou o único a passar por essa situação. Quais estrategias posso adotar? Saudações, Luiz Paulo

Bom dia, pessoal! Tudo bem? Estou desenvolvendo o envio do NFCe num aplicativo aqui da empresa onde trabalho, gostaria de saber como faço para configurar o ACBr para envio pelo webservice parece que do Amazonas, que é o que está valendo, certo? Att, Rafael Hassegawa

Bom dia, Trabalho em uma Software House e, há algum tempo passei a receber a rejeição 481 - Código Regime Tributário do emitente diverge do cadastro na SEFAZ, em virtude dos testes que realizava. Ou seja, antes eu emitia notas em homologação para testar as CSTs do regime normal bem como do Simples nacional, tudo com o mesmo emitente / certificado. Neste sentido, visto que estou impossibilitado de realizar os testes como antes, gostaria de saber qual a solução adotada neste caso, se é necessário criar uma nova empresa, ou se é possível apenas comprar algum outro "tipo" de certificado, ou se a empresa precisa incluir alguma nova função junto à contabilidade, ou se é apenas algum parâmetro que deve ser informado de forma diferente, enfim, acredito que não sou só eu com esta dificuldade.. Como vocês estão fazendo para realizar os testes? Obrigado.

Pessoal, Alguém tem informações sobre o ambiente que configuramos no CFe, se produção ou testes? No SATTeste tem a opção para configurara este campo, mas o manual diz que quem coloca esta informação é o SAT. Será que há possibilidade de ficar trocando entre homologação e testes? Valeu.

Boa tarde, Pessoal! Estou iniciando o desenvolvimento do SAT em nossa aplicação e gostaria de saber qual melhor aparelho SAT para realizar o desenvolvimento e testes de suporte. Alguém saberia me dizer qual o melhor ou mais utilizado para o desenvolvimento e testes do projeto? Fico no aguardo. Obrigado! Raphael

Bom dia a todos, Alguém de Alagoas para me ajudar em uma questão ou que tenha clientes com o PAF em Alagoas? É o seguinte fizemos toda parte de registro da empresa e software junto ao Sefaz de Alagos está tudo ok, porém, esse cliente acaba de adquirir uma nova impressora fiscal Sweda e o seu contador está dizendo que para lacrar a impressora temos que fazer os testes de vendas com nosso sistema na impressora, mas como faremos estes testes se a impressora não está lacrada, está sem informação alguma. Alguém que tenha passado por algo parecido que possa nos ajudar?

Olá escovadores de bits, Hoje nosso escovando será um pouco diferente, vamos analisar o hardware da impressora fiscal. Analisaremos o sensor de papel da ECF para entender como a impressora identifica que a bobina está próxima do fim ou não. Muitos parceiros nos procuram com duvidas sobre o sensor de papel, nos questionam se o retorno dado pela ECF está correto mesmo ou não. Uma frase de exemplo: “A impressora está retornando papel acabando, mas a minha bobina está cheia! O que faço?”. Este escovando é especial para estes parceiros, pois vamos mostrar de duas formas quando é que o papel realmente está acabando. Hardware – Vamos identificar onde é o mágico sensor de pouco papel e de sem papel. Imagens ilustrativas da impressora fiscal irão ajudá-los na identificação. Software – Nesta etapa vamos testar se o que está na impressora(hardware) condiz com o retorno recebido. Simularemos pouco papel e sem papel na ECF. Escovadores de Bits, acho que agora vocês entenderam que o tema de hoje será bastante usado por vocês né?! Acompanhem este rápido e importante escovando bits. Continue lendo: http://www.desenvolvedoresdaruma.com.br/dde/htmls/dde055_2013_sensor_de_papel.html Abraços,