Ir para conteúdo
  • Cadastre-se

_asseinfo

Membros
  • Total de ítens

    208
  • Registro em

  • Última visita

Tudo que _asseinfo postou

  1. Vou deixar aqui o fim da thread caso alguém mais tenha esta dúvida. Basta fazer um patch para a API mudando o status para REMOVIDA_PELO_USUARIO_RECEBEDOR. Endpoint: /cobv/{txid} Payload: { "status": "REMOVIDA_PELO_USUARIO_RECEBEDOR" } Muito obrigado
  2. Estava lendo diretamente a documentação dos endpoints do BACEN. Vou baixar os fontes pra dar uma olhadinha. Muito obrigado pela orientação.
  3. Eu não encontrei um endpoint específico para cancelamento. Seria fazer um patch enviando o status "REMOVIDA_PELO_USUARIO_RECEBEDOR"? Muito obrigado.
  4. Olá?! Algumas vezes acontece do usuário registrar um pixcobv, enviar para o cliente dele e depois se arrepender por algum motivo bizarro. Recebemos um questionamento se não haveria uma forma de cancelar este Pix cobrança com vencimento para evitar que o cliente acabe pagando ele equivocadamente. Como vocês estão lidando com esta situação? Muito obrigado.
  5. @JHONLENON obrigado por reforçar a mensagem lá para os caras. Eu estou com um ticket aberto com eles lá em Brasília com mais de 60 dias. Essa semana vou gravar um vídeo com os argumentos que havia te dito e mandar pra eles em um novo ticket. Vou também gravar como é o processo do Inter - com a geração do certificado digital por eles mesmo - pra ver a simplicidade. Pra gente aqui o Sicoob se tornou um pesadelo. Inclusive, suspendemos a liberação da rotina pra novos licenciados (e estamos perdendo algumas vendas por conta disso). Tivemos até gerente desinformando dando uma de técnico de informática para o nosso cliente e dizendo que nosso software é inseguro porque não temos IP fixo . O mesmo cara que oferece título de capitalização como investimento é o mesmo que agora é especialista em segurança digital . Haja paciência.
  6. @JHONLENON putz! Que oportunidade, cara. A melhor maneira desse problema ser resolvido seria eles facilitando esse processo. Nós temos software web há 8 anos e emitimos boletos via API há 4,5 anos via PJBank (fará cinco agora no mês 7). Temos integração com diversos bancos e o mais sofrido é o Sicoob (temos também outro software Desktop com 21 anos - usando acbr). Nós implementamos a V1 com o fluxo de autenticação antigo e temos diversos licenciados rodando. Foi bem chatinho de fazer. Em nossa avaliação o novo fluxo de autenticação é um tiro no pé do próprio banco. Eis alguns motivos: a. Nem todo fornecedor de ERP tem experiência com web. Vários irão pelo caminho de fazer diretamente no desktop. Isso fará com que o custo do IP fixo + certificado acabe caindo para o licenciado. A gente sabe que muitos correntistas que optam pelo Sicoob é pelo baixo preço do boleto. b. Quem se aventurar em montar um servidor web para fazer o papel de proxy entre o banco e o ERP desktop terá que ter cuidado redobrado com o aplicativo. Se a pessoa não tiver experiência, pode acabar deixando brechas para ataques. Sem contar que esse software precisa ser constantemente atualizado - frameworks envelhecem rápido. Lembrando que o certificado A1 provavelmente terá que ficar nessa máquina para assinar o request. A web não é brincadeira - ainda mais quando se trata de transações financeiras. c. Acreditamos que a explosão de IP fixos pode ser bem chato para o firewall do banco no futuro. d. Mesmo nós que estamos na web, ter IP fixo é chato. A gente trabalha com elastic cloud e nunca sabemos os IPs e nem mesmo quantos servidores estão rodando. Teremos que alugar um IP fixo e tunelar nossa comunicação com o Sicoob através dele. Entendemos que o banco precisa de segurança, mas acreditamos que existem outros meios mais acessíveis pra isso. Um exemplo é o Banco Inter. Você mesmo emite o certificado no Internet Banking deles e o IP fixo não é requerido. Seria muito parecido com o novo fluxo do Sicoob. Se for do seu interesse, eu posso até gravar um vídeo falando sobre o que eu escrevi acima. Muito obrigado.
  7. A gente até vem conseguindo a liberação do uso da V1, mas é um inferno . Eu estou me organizando aqui pra colocar um par de devs pra reescrever nossa integração pra V2. O que mais está nos ferrando mesmo é essa exigência maluca de ter um IP fixo para liberar no firewall dos caras. Vamos ter que ter uma infra adicional por conta disso (e custos desnecessários). É uma pena o suporte deles ser tão omisso. Não tem nem chance de conversar com ninguém a respeito do problema, pois eles só respondem o que é conveniente. Outro pé no saco é que só vai dar pra atender quem tem A1. Depois eu vou fazer um teste se o certificado precisa ser do correntista ou se ele usa somente para certificar o autor da comunicação (como acontece na NF-e: o XML precisa ser assinado pelo certificado do emissor, mas a transmissão pode ser feita com o certificado de um terceiro). Se o certificado só servir para a comunicação então aqui nós podemos usar o da própria softhouse. Assim, licenciados que possuem o A3 não ficarão na mão. Vamos trocando uma ideia por aqui.
  8. Olá?! Não sei se alguém aqui tentou recentemente credenciar algum correntista no Sicoob, mas agora os caras não estão mais aceitando via Authorization Code. Pelo que vimos, tem que usar a V2 e Client Credential. Temos clientes em várias partes do país e as agências, no geral, não sabem ao certo o que fazer. Duas coisas que ferram o uso do Client Credential: a. Precisa ter um certificado digital b. Precisa ter um IP fixo para cadastrar no firewall do banco. O suporte dos caras é bem complicado. Você escreve pra lá, o ticket é aberto e simplesmente ninguém responde. Nossos clientes que ainda usam o Authorization Code estão funcionando sem problema. O credenciamento de novos correntistas não estamos mais conseguindo fazer. Alguém está passando por dificuldades com eles também? Muito obrigado.
  9. Olá pessoal, enfrentamos esse problema ontem o dia todo também. Nosso problema acontece com a emissão de NF-e em SC. Recomendo reportarem de forma profissional e séria junto a SEFAZ DE SC, usando o formulário http://caf2.sef.sc.gov.br/Views/Shared/NovoTicket.aspx. Acredito que se todos reportarem problemas, eles vão investigar novamente. Na outra vez, tinha problemas e foram resolvidos. Abraços e bom trabalho.
  10. Olá galera, recebi a resposta da SEFAZ de SC. Era problema com o webservice mesmo. Imagem:
  11. Olá pessoal, se vocês estão com problemas (HTTP error (403)) em SC também, seria legal reportar no formulário do link abaixo: http://caf2.sef.sc.gov.br/Views/Shared/NovoTicket.aspx Até mais.
  12. Estou enfrentando o mesmo problema. Alguém já encontrou algum padrão? Aqui só estou tendo problemas em SC.
  13. Muito obrigado @oraculum, sua resposta foi de grande ajuda. Abraço!
  14. Olá pessoal! Alguém aqui por acaso usa em SP a NFCe ao invés do SAT? Isso é possível? Existe alguma condição especial ou é apenas uma escolha do contribuinte? Muito obrigado.
  15. Boa tarde pessoal, consegui revolver, havia deixado a tag </ dest> vazia. Removendo ela totalmente, consegui autorizar. Muito obrigado
  16. Olá pessoal Já conseguimos autorizar algumas NFC-es em homologação para o Amazonas, porém não conseguimos autorizar uma NFC-e sem o destinatário, onde o consumidor não é informado. Deixamos várias tags sem informar e outras em branco, como por exemplo xNome. Porém a SEFAZ AM rejeita quando não informamos: - Indicador da IE - CPF/CNPJ Pela documentação da SEFAZ AM, se o valor for inferior a R$ 10.000,00, é possível emitir sem destinatário. Alguém sabe se há alguma limitação em homologação, ou estamos esquecendo de algo? Muito obrigado
  17. Obrigado pela resposta, Juliana. A minha dúvida é como fazer isto com o ACBR. Já usamos o ACBR faz algum tempo aqui, o básico de vender itens e as configurações, eu já conheço. Mas gostaria de saber, de que maneira posso fazer isso utilizando o ACBR, caso seja possível. Também notei que os códigos são menores, assim como os nomes dos produtos neste exemplo de cupom. Mas minha dúvida, como citei acima, é como fazer isto com o ACBR. Entendo que é possível verificar quantos caracteres serão impressos e atuar em cima disso, variado a flag DescricaoGrande que tem no ACBREcf. E também entendo que isso me libera espaço para imprimir muitos caracteres que ele vai quebrar a linha. Só que muitos clientes são meio relaxados com os nomes de seus produtos e eles ficam enormes, acarretando em várias linha impressas por item, em um cupom. Novamente, também entendo que é possível lidar com isto manualmente, truncando a descrição do produto para que ele fique em duas linhas. Mas atendemos muitos ecfs diferentes, e eles podem ter algumas peculiaridades em relação aos tamanhos por linha, eu mesmo já passei por problemas por causa de algumas peculiaridades de ECFs diferentes. Por isto pergunto se existe alguma maneira de fazer isto utilizando o ACBR, sem ter que truncar manualmente a descrição dos produtos.
  18. Então, Daniel, não sei se me dei bem a entender. Sim, ele foi emitido por um ECF, porém note que em alguns casos ele utiliza somente uma linha, para colocar toda a informação e em outros casos ele utiliza duas linhas, de forma bem organizada. A minha dúvida é como fazer isto com o ACBR.
  19. Bom dia. Aqui na cidade, em SC, existe uma rede de super mercados, que é bem grande regionalmente, este dispõe os itens do cupom fiscal desta maneira. Já olhei o funcionamento da propriedade "DescricaoGrande", o que ela faz é permitir que as informações do produto sejam quebradas. Criando a possibilidade de uma descrição maior. Gostaria de saber se existe alguma configuração que possa ser feita, para o cupom sair desta forma, em duas linhas, não em múltiplas. Quero fugir de ter que ficar fazendo configurações para ecfs diferentes. Por exemplo: Se um ECF imprimir 44 colunas, outra imprimir 43 e outra ainda, imprimir 42. Eu acabaria tendo que ficar caçando isso, vocês conhecem alguma configuração que resolva isso?
  20. Opa, ainda se mantem esta situação? Pois estou com o mesmo problema em homologação e funciona, mas em produção dá erro, me parece que o WSDL está com erro na URL do serviço, confira na url de produção: http://nfe.sefaz.am.gov.br/services2/services/NfeAutorizacao4?wsdl <wsdl:service name="NfeAutorizacao4"> <wsdl:port name="NfeAutorizacao4Soap12" binding="tns:NfeAutorizacao4Soap12"> <soap12:address location="https://nfe.sefaz.am.gov.br/services2/services/NFeAutorizacao4"/> </wsdl:port> </wsdl:service> Já o de homologação está correto, confira na url de homologação: http://homnfe.sefaz.am.gov.br/services2/services/NfeAutorizacao4?wsdl <wsdl:service name="NfeAutorizacao4"> <wsdl:port name="NfeAutorizacao4Soap12" binding="tns:NfeAutorizacao4Soap12"> <soap12:address location="https://homnfe.sefaz.am.gov.br/services2/services/NfeAutorizacao4"/> </wsdl:port> </wsdl:service> Vocês estão usando o 3.10 ainda para autorizar notas em Amazonas?
  21. Senhores, estou com o mesmo problema também. Como já lancei o problema em outro tópico, vai aqui o link para não ser redundante.
  22. Senhores, boa tarde Atualizei o ACBR em 19/06/2018 e ao fazer o evento de cancelamento o XML formado fica dessa forma: <envEvento xmlns="http://www.portalfiscal.inf.br/nfe" versao="4.00"> <idLote>1</idLote> <evento xmlns="http://www.portalfiscal.inf.br/nfe" versao="4.00"> <infEvento Id="..."> <cOrgao>42</cOrgao> <tpAmb>2</tpAmb> <CNPJ>...</CNPJ> <chNFe>...</chNFe> <dhEvento>2018-06-25T15:53:05-03:00</dhEvento> <tpEvento>110111</tpEvento> <nSeqEvento>1</nSeqEvento> <verEvento>4.00</verEvento> <detEvento versao="4.00"> <descEvento>Cancelamento</descEvento> Dessa forma o evento não autoriza na SEFAZ (Estou em Santa Catarina). O mesmo acontece com qualquer outro evento (CC-e, Manifestação) Para aceitar eu precisei mudar o a versão para 1.00 em todos os lugares onde destaquei em negrito, conforme sugerido pelo basiliusvalentinus. Porém, inspecionando o código onde é gerado o XML temos o seguinte: (Arquivo pcnEnvEventoNFe.pas) function TEventoNFe.GerarXML: Boolean; var i, j: Integer; sDoc, sModelo: String; begin Gerador.ArquivoFormatoXML := ''; Gerador.wGrupo('envEvento ' + NAME_SPACE + ' versao="' + Versao + '"'); Gerador.wCampo(tcInt, 'HP03', 'idLote', 001, 015, 1, FidLote, DSC_IDLOTE); ... Gerador.wGrupo('evento ' + NAME_SPACE + ' versao="' + Versao + '"'); ... Gerador.wCampo(tcStr, 'HP16', 'verEvento', 001, 004, 1, Versao); // Evento.Items[i].InfEvento.versaoEvento); Gerador.wGrupo('detEvento versao="' + Versao + '"'); A variável Versao é alimentada no arquivo ACBrNFeWebServices.pas, no método TNFeEnvEvento.DefinirDadosMsg: EventoNFe.Versao := FPVersaoServico; A variável, FPVersaoServico por sua vez é alimentada pelo método TNFeWebService.DefinirURL, no mesmo arquivo: TACBrNFe(FPDFeOwner).LerServicoDeParams(FPLayout, Versao, FPURL, FPServico, FPSoapAction); FPVersaoServico := FloatToString(Versao, '.', '0.00'); E o método LerServicoDeParams vai buscar o valor para a variável local Versao a partir da versão da NF-e através da propriedade Configuracoes.Geral.VersaoDF que contém o valor ve400 (TACBrNFe.LerServicoDeParams no arquivo ACBrNFe.ini) Enfim, para que os eventos pudessem ser aceitos, eu modifiquei (em minha cópia local) lá no evento GerarXML do arquivo pcnEnvEventoNFe.pas colocando fixo 1.00 no lugar da variável Versao. Minha questão é: Seria esse o procedimento mais correto? Alguém já atentou para esse código? Se puderem me ajudar, agradeço.
  23. O código acima, eu utilizei aqui, no código do acbr, para fazer o teste de desempenho, aliás.
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.