Jump to content

logo_acbr_paygo.png

Chegou o TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


botao_saibamais.png

beneficios.png

Curso Dominando o ACBrMonitor
Novo Módulo Soluções de Varejo
Assine o SAC ACBr em qualquer plano e tenha acesso

Saiba Mais

Balança SM100 performance surpreendente

Tecnologia Japonesa   Teclado e Visor resistentes a água
Consumo inteligente de etiquetas   Baixo custo de manutenção
Comunicação Ethernet e WIFI independentes

Saiba Mais

Impressora de Etiquetas ELGIN - L42 PRO

Protocolos PPLA, PPLB, ZPL, EPL (automático)
Porta USB padrão Opcionais: Ethernet, Serial, Paralela
Sensor de Etiquetas Móvel Garantia de 18 meses

Saiba mais

João Paulo Müller

Membros
  • Content Count

    314
  • Joined

  • Last visited

  • Days Won

    2

João Paulo Müller last won the day on November 5 2017

João Paulo Müller had the most liked content!

Community Reputation

80 Excellent

3 Followers

About João Paulo Müller

  • Rank
    Membro Ativo
  • Birthday 01/01/1991

Profile Information

  • Sexo
    Masculino
  • Localização
    Rio do sul - SC

Recent Profile Visitors

1,484 profile views
  1. Claro Daniel, está certo. Perdão, fiz a anlise em cima da minha própria sugestão de alteração, por isso estária incorreto... O código do repositório é esse mesmo que você comentou e vai funcionar perfeitamente. Obrigado!
  2. Olá Daniel, agradeço o retorno. Acredito que atribuindo o valor 1 nesse else deixará a próxima condição em sequencia sem lógica: [...] if I = 0 then I := PosEx(IdAttr+'=', AXML) // offset default é 1 else I := PosEx(IdAttr+'=', AXML, I) [...] Vai funcionar da mesma forma, pois ira cair no else e chamar o terceiro parametro (I) com o valor 1, mas acredito que esse IF I = 0 não terá mais uso, pois em nenhum momento será atribuido o valor 0 a váriavel I, confere?
  3. Opa, fiz a alteração que você sugeriu e funcionou perfeitamente em ambiente de homologação. Vou fazer um teste em produção para confirmar. Pensei que iria dar problema na rotina a baixo que identifica o final da tag docElement, por isso acabei não mexendo nessa rotina. //Função AdicionarSignatureElement URI := EncontrarURI(ConteudoXML, docElement, IdAttr); TagEndDocElement := '</' + docElement + '>'; I := PosLast(TagEndDocElement, ConteudoXML); if I = 0 then raise EACBrDFeException.Create('Não encontrei final do elemento: ' + TagEndDocElement); [...] @BigWings Obrigado pela ajuda e atenção.
  4. Boa tarde, @BigWings. Utilizo o componente apenas para fazer a assinatura e envio do XML atráves da classe ACBrDFeSSL, não utilizo o componente ACBrNFSe por completo. Faço a assinatura da seguinte forma: A := ACBrDFE.Assinar(XML, 'Pedido></CancelarNfseEnvio', 'InfPedidoCancelamento'); Acredito que a função EncontrarURI da forma que está pode acabar gerando problemas para outros provedores em casos que não encontrar o DocElement, consequentemente a variavel I receber o valor 0 (o qual está incorreto, pois o offset deveria ser 1). Entendo que com a sugestão proposta a baixo resolveria por completo a situação, tanto do meu caso, quanto para outros cenários em que o DocElement não for encontrado, ou seja, não seria uma implementação especifica para min, mas sim uma correção de bug. [...] if (docElement <> '') then I := Pos('<'+docElement, AXML) else I := 0; if I = 0 then I := PosEx(IdAttr+'=', AXML) // offset default é 1 else I := PosEx(IdAttr+'=', AXML, I) [...]
  5. Segue em anexo Unit alterada. ACBrDFeUtil.pas
  6. Boa tarde, Pessoal. Encontrei onde está o problema, acontece que da revision 17491 para a revision atual teve alterações na função ExtraiURI, que passou a se chamar EncontrarURI e teve sua estrutura alterada. Encontrei o erro na seguinte rotina: [...] if (docElement <> '') then I := Pos('<'+docElement, AXML) else I := 0; //AQUI QUANDO É PASSODO O PARAMETRO I O VALOR ESTÁ 0, NO ENTANTO, O OFFSET PADRÃO SERIA 1 I := PosEx(IdAttr+'=', AXML, I); if I = 0 then // XML não tem URI Exit; [...] Pelo que pude perceber o parametro offset da função PosEx deveria inciar em 1 não 0, como na rotina acima onde é feito o Pos no docElement está retornando o valor 0 para a variavel I, está sendo passado o valor 0 para o parametro offset, o qual tem seu valor default 1. Acredito que seria incorreto atribuirmos o valor 1 para a variavel I, devido a comparação posterior para verificar se foi encontrado a URI no XML, portanto dexei a seguinte sugestão de alteração: [...] if (docElement <> '') then I := Pos('<'+docElement, AXML) else I := 0; if I = 0 then I := PosEx(IdAttr+'=', AXML) // offset default é 1 else I := PosEx(IdAttr+'=', AXML, I) [...] Peço por gentileza se os moderadores/commiters poderiam analisar essa sugestão de alteração. Grato!
  7. Olá Prezados, Estou com erro no cancelamento da NFs de Betha. Ao cancelar a nota recebo um XML apenas com Fault String 172, pelo codigo indica um erro de assinatura. Notei que nas versões anteriores do sistema esse erro não estava ocorrendo, então voltei o ACBr para a revision que o cancelamento estava funcionando e voltou a funcionar. Voltei para a revision 17491 e consegui fazer o cancelamento normalmente. Ao analisar os XML notei a seguinte diferença na contrução do XML para cancelamento: No arquivo a esquerda esta funcionando, portanto, notei que a diferença está no <Reference URI="#canc3". Alguém poderia me orientar como faço para inserir essa URI="#canc3" na revision atual? OBS: Para esse municipio realizamos a contrução do XML manualmente e utilizamos o compontene ACBr apenas para realizar o envio e assinatura.
  8. Obrigado pelo Retorno. Legal, assim que obter o retorno compartilhe essa informação conosco. Com relação a InfPag, você já implementou ? Como implementou ou pretende implementar? Estou pensando em disponibilizar os campos para preenchimento do usuário. Existe algum tipo de integração pra facilitar o preenchimento dessas informações?
  9. Boa tarde pessoal, estive analisando a NT 2020.001 e pude observar que agora será gerado o CIOT automaticamente pelo MDFe. Nesse caso não será mais necessário o preenchimento das tags do grupo <infCIOT> ? Estou em dúvida pois vejo no fórum um fluxo bem grande sobre o componente ACBrCIOT. Esse componente é utilizado para geração do CIOT, confere? Mas se o CIOT será gerado automaticamente pelo MDFe então não será mais necessário o uso deste componente? Há alguma outra necessidade de uso desse componente (ACBrCIOT) ? Vi no fórum o pessoal usando o evento proprietário do veículo, porém não entendi a necessidade do mesmo. Ainda sobre o CIOT, o Italo publicou um tópico sobre a grande preocupação em gerar o CIOT, mas essa informação já não existia anteriormente através do grupo <InfCIOT> ? Outra dúvida que tenho é sobre o grupo <InfPag>, como estão tratando o preenchimento das informações deste grupo? Disponibilizam os campos para o usuário parametrizar ou há alguma integração necessária? Agradeço a atenção.
  10. Bom dia Pessoal, Tivemos a solicitação de um cliente para enviar o valor total dos tributos ( soma das alíquotas Federal + Estadual + Municipal, conforme confirmado com Pedro - SimplISS). Analisando o componente NFSe notei que na unit pnfsNFSeW_ABRASFv2 o campo era preenchido com 0 Gerador.wCampoNFSe(tcDe2, '#22', 'ValTotTributos ', 01, 15, 1, 0.0, DSC_VINSS); Alterei para preencher com uma nova propriedade criada Gerador.wCampoNFSe(tcDe2, '#22', 'ValTotTributos ', 01, 15, 1, NFSe.Servico.Valores.ValorTotalTributos); Realizei o ajuste no componente para enviar esse campo conforme valor definido na nova propriedade que criei: Unit pnfsNFSe; .... // Alterado Linha 185 e 227 TValores = class(TObject) private FValorServicos: Currency; FValorDeducoes: Currency; ... FvValorTotalTributos: currency; public property ValorServicos: Currency read FValorServicos write FValorServicos; property ValorDeducoes: Currency read FValorDeducoes write FValorDeducoes; ... //Provedor proSimplISSv2 property ValorTotalTributos: currency read FvValorTotalTributos write FvValorTotalTributos; end; Realizei os testes e esta funcionando corretamente. Alguém poderia analisar e fazer o commit? Anexei as unit para analise. pnfsNFSe.pas pnfsNFSeW_ABRASFv2.pas
  11. Boa tarde. O WS de migração deles possui apenas o ambiente de Produção, já os demais WS possui os dois ambientes (Homologação e Produção).
  12. Boa tarde Ernesto, Esse defeito é em ambiente de homologação, produção ou ambos?
  13. Bom dia Pessoal, Mais uma informação: Para fazer o envio da nota utilizando o método enviar (recepcionar) é necessário assinar o RPS. Fiz alguns testes sem assinar o RPS e ao consultar o lote retorna o erro informado que o campo ListaRPs[]Rps.Signature está faltando. Ao marcar no arquivo SimplISSv2 para assinar o RPS, tudo funcionou perfeitamente. [Assinar] RPS=1 Peço que se possível realizem a analise para subir essa alteração no SVN. Grato! SimplISSv2.ini
  14. Pessoal realizei algumas alterações no arquivo SimplISSv2.ini nos métodos de consultar lote e consultar RPS. Pelos testes que fiz aqui é para estar funcionando esses dois métodos. Segue em anexo para quem quiser testar e se possível @Italo Jurisato Junior analisar para subir no repositório. SimplISSv2.ini
  15. Bom dia, Para esse provedor a consulta da situação do lote deve ser feita através do método ConsultaLoteRPS, se a consulta retornar a nota então o lote foi aprovado, caso contrário será retornado a situação do lote (Segundo o suporte da SimplISS, pois não consegui testar ainda). O detalhe é que atualmente os métodos de consultas estão retornando erro de "Value cannot be null, parameter name: S", estou em contato com o suporte para tentar resolver esse problema, mas até agora não conseguimos identificar o problema. Vou fazer uns testes pelo SoapUI para ver se funciona.
×
×
  • Create New...