Rodrigo Reis Mattos

Obrigado pela resposta, conforme orientações da prefeitura a URL é https://sobradinho.atende.net/?pg=rest&service=WNERestServiceNFSe, porém tentei enviar mas o retorno é: <retorno> <mensagem> <codigo>9999 - Arquivo XML da Nota Fiscal de Serviço Eletrônica não enviado!</codigo> </mensagem> </retorno>

Olá, Recentemente Sobradinho - RS atualizou seu Sistema Fiscal Web e está utilizando o provedor IPM https://sobradinho.atende.net/subportal/atualizacao-do-sistema-fiscal-web Estou migrando o componente ACBrNFSe para o ACBrNFSeX, pelo que consultei, o arquivo ACBrNFSeXServicos.ini ainda não foi atualizado com as informações do provedor. Alguma previsão ou estou me equivocando em algo?

Olá, Testei o retorno do arquivo eletrônico de pagamento com o banco Bradesco e não funcionou. O retorno está sendo feito com 3 linhas de detalhes, sendo elas 3J, 3J (52) e 3Z. Sendo assim a leitura do TXT não ocorreu devido os erros abaixo: 1. Erro de conversão de datas ao ler o detalhe 3J (52) na linha: FPagFor.Lote.Last.SegmentoJ.Last.DataVencimento := StringToDateTime(Copy(FArquivoTXT.Strings[i], 92, 2)+'/'+Copy(FArquivoTXT.Strings[i], 94, 2)+'/'+Copy(FArquivoTXT.Strings[i], 96, 4)); Isto porque a posição 92 é o nome do cedente. 2. Teve que ser adicionado o tipo pagBradesco junto dos campos pagItau, pagSantander, pagSicred para ler ValorTitulo, Desconto, .... 3. Adicionado o tipo pagBradesco junto do pagSicred para leitura do "NossoNumero" nas posições 203/20. 4. Para leitura dos segmentos J52, B, C e Z nas respectivas procedures LerSegmentoJ52, LerSegmentoB, LerSegmentoC e LerSegmentoZ entendo que não deve passar pela leitura do 3J normal. Segue em anexo a unit ACBrPagForLerTxt com as alterações realizadas para homologação. ACBrPagForLerTxt.pas

Olá Marcelo! Sim! kkkk, esta informação surgiu do BC no final do dia 29/10/2020 e veio para atender as necessidades do B2B. Em breve teremos que implementar esta funcionalidade. A única coisa que não foi respondida é se poderá ser utilizado para protesto.

Em resposta a todos que pesquisarem sobre o assunto: Foi feito reunião entre a PayGo, ACBr e eu, nela foi constatado que um software destinado à B2B, onde não há iteração com consumidor, o PIX (no primeiro momento) não é o mais indicado. Isto porque num ambiente onde uma indústria vende para outra indústria, o procedimento mais utilizado é o faturamento da mercadoria e a emissão de boletos para pagamentos futuro (14DD, 28DD, 15FM, ect...). O PIX é um produto para pagamento imediato, onde o emissor aguardará o pagamento, se não naquele instante da venda; no mesmo dia! Um assunto também discutido na reunião foi que o PIX não é um possível gerador de um protesto, caso não for pago. Diferentemente do boleto, onde ele é um meio para protesto e muitas empresas utilizam o mesmo para o devido fim, caso não tenham uma confirmação do pagamento de seus clientes (empresas). A PayGo, caso não seja possível a utilização do TEF do ACBr, possui um Gateway de Pagamento onde é possível ser utilizado num ambiente B2B por exemplo. Mas os cuidados acima deverão ser levados em consideração! @Daniel Simoes, acho que é isto né? Tem algo a mais a contribuir que eu não mencionei? Podemos fechar o tópico?

Daniel, mas é isto que eu preciso! Gerar um QrCode dinâmico para enviar ao cliente para que ele pague, para substituir o boleto. Seria desta forma?

@Daniel Simoes, ao emitir uma NFe, por exemplo, meu sistema gera os títulos para pagamento da mesma, se caso o cliente desejar pagar via PIX eu teria que gerar o QrCode para ele. Pelo que eu entendi, a chave poderia estar vinculada ao meu título e então eu tenho a rastreabilidade necessária. Eu poderia consultar a chave e validar se o título foi pago ou não?

Olá, Trabalho em uma software house e temos um sistema aplicado em indústrias (B2B), ou seja, não é um sistema para o consumidor final. Porém com a entrada do PIX, poderemos ter emissões de boletos que poderão ser pagos da forma tradicional ou com o PIX. Porém nosso sistema não possui TEF. Assistindo à palestra do Daniel no Dia do ACBr sobre o PIX e homologação com a PayGo, pude ter uma noção de como iria funcionar. Até pensei que nós poderíamos integrar nosso sistema ao TEF e caso nosso cliente informar a opção PIX, já viria automaticamente a forma de pagamento dele. Porém, entrei em contato com o ACBr e me foi informado que não iria funcionar desta forma, pois esta seria uma opção apenas para o cliente final (consumidor) na frente de um caixa, por exemplo, ou seja, B2C. Então, solicitei contato com a PayGo para uma possível conversa para uma integração, porém faz mais de uma semana e ninguém retorna. Será que alguém pode me ajudar? O prazo está chegando e não sei o que fazer....

Srs, Como as Software Houses estão conseguindo emitir e validar os XMLs no Sefaz (homologação) sem o certificado digital de algum cliente? Recentemente, o cliente que nos fornecia o certificado digital para testes em homologação com o seu ambiente não cedeu mais. Isto fez com que nós entrássemos em contato com o Sefaz e nos foi fornecido uma inscrição estadual para que emitíssemos as NFes em homologação. OBS: Temos o nosso certificado digital. O problema é que sempre retorna com rejeição 203 - Empresa não autorizada. Em contato com o Sefaz - RS, ninguém dá retorno. Alguém, de alguma software house do RS emite NFes em homologação com seu próprio certificado? Poderiam nos dar uma ajuda de como procederam para tal? Desde já agradeço.