Vinicius Telles dos Santos

Boa tarde, pessoal! Um de nossos clientes solicitou a implementação do PIX do Mercado Pago, e verificamos que hoje está versionado o PSP deste banco, porém aqui no fórum foi comentado que este foi desativado. Minha dúvida é se é possível utilizar esta rota ou se possui alguma falha, pois funcionou normalmente após inserirmos a URL novamente. Caso não seja adequado utilizá-la, o Mercado Pago repassou qual seria a rota adequada? Aí podemos analisar a implementação internamente e compartilhar o fonte com o ACBr também.

Um dos membros aqui do ACBr me retornou com a solução. Estarei deixando abaixo para quem tiver o mesmo retorno: Solução: Precisa habilitar o indicador 182 – COBRANÇA COM QR CODE no contrato de cobrança do cliente, e também cadastrar uma chave pix aleatória. Caso o contrato de cobrança foi feito pelo Net Empresa Bradesco, o próprio cliente correntista consegue alterar o contrato de cobrança, agora, se foi assinado via documento na agência, aí só com gerente PJ Bradesco na agência.

Boa tarde, pessoal. Estou com um cliente tentando emitir um boleto em produção utilizando a API do banco Bradesco, porém o retorno que está obtendo é "IDENTIFICADOR DO PRODUTO NAO CADASTRADO". Em homologação para este mesmo cliente emitiu sem problemas, apenas em produção retorna esta mensagem. Já pegaram esta situação? Se sim, como resolveram?

Ao consultar um CPF através do componente ACBrConsultaCPF, ao tentar gerar o Captcha para autenticação, está gerando a seguinte exceção: HTTP 500 - Socket Error: 10091 Network subsystem is unusable. Ao acessar o site de consulta de CPF da receita através do navegador, apresenta grande demora e após finalizar o carregamento do site a imagem do Captcha não é carregada. O fonte do ACBr está atualizado, seria um problema com o link utilizado para consulta? Ou alguma situação específica do site da receita?

Comparamos com os exemplos do ACBr e também setamos como False a property "ConfirmarAntesDosComprovantes", porém os resultados foram os mesmos. Continuaremos analisando a situação para identificar a causa. Obrigado pelo auxílio.

Exato, foi esta minha compreensão após a leitura da NT, porém consegui emitir dois eventos de Insucesso para o mesmo CTe, sem realizar o Cancelamento do Insucesso na Entrega já emitido anteriormente, apenas aumentando o número sequencial. Por isso levantei o questionamento.

Bom dia, Realizando testes em homologação para envio do evento de Insucesso na Entrega, percebi que é possível registrar mais que um deste evento para o mesmo CTe, apenas aumentando o número sequencial do evento. Porém, ao analisar a documentação e as regras de validação disponíveis na NT, vi que não deveria ser possível associar mais que um evento de Insucesso para o mesmo CTe. Alguém já observou a mesma situação? Trata-se de uma falha na validação da Sefaz?

Bom dia. Ao finalizar uma venda com o TEF Sitef (Dedicado), solicita a inserção/aproximação do cartão e retorna a mensagem "Aprovada XXXXXX" (X corresponde ao número da transação), porém a venda não é finalizada. A situação ocorre apenas em duas máquinas, em outras foi realizado testes e o processo funcionou normalmente. Segue em anexo trecho do log CliSitef gerado, onde é possível perceber que algumas funções não foram executadas nas máquinas em que a situação vem ocorrendo. Alguém já passou por esta situação? Não conseguimos identificar diferenças que pudessem ocasionar a situação.

Também estou com a mesma situação ao tentar emitir no PR. Espero por algum retorno também.

Obrigado, Italo. Continuarei observando as atualizações referentes ao CT-e 4.00 para saber como deverá ser gerido o processo para os não contribuintes.

Bom dia! Ao analisar as notas técnicas e documentos referentes ao CT-e v4.00, podemos ver que o CT-e de anulação será eliminado. Porém não encontrei em nenhum local uma descrição de como será a "nova sistemática de substituição" que será aplicada na versão 4.00. Antes era necessário associar um CT-e de anulação para efetuar a substituição. Como o processo irá ocorrer de agora em diante?