VEXCOM Sistemas - Valtair

Houve mudanças no provedor IPM de São Carlos / SC

já fiz o teste alterando o arquivo ACBrNFSeXServicos.ini e compilando o res

após alterar esse bloco

 
[4216008] ; Atualizado em 28/10/2024 Nome=Sao Carlos UF=SC Provedor=IPM Versao=1.01 Params=NaoGerarGrupoRps ProRecepcionar=https://ws-saocarlos.atende.net:7443/atende.php?pg=rest&service=WNERestServiceNFSe HomRecepcionar=https://treinamento.atende.net/?pg=rest&service=WNERestServiceNFSe&cidade=treina_saocarlos a Nota fiscal de serviço foi transmitida, testei apenas em ambiente de produção, somente segui a mesma regra de homologação para o mesmo cenário do mesmo provedor, porém de outras cidades.

Contribuindo com o projeto ACBr, solicito, se possível alguns ajustes, tenho clientes que enviam NFSe nestas cidades, e após os ajustes abaixo, as NFSes estão sendo transmitidas com sucesso. Essas alterações não foram feitas hoje, faz um certo tempo já, então estão funcionando perfeitamente.

no arquivo INI: "ACBr\trunk2\Fontes\ACBrDFe\ACBrNFSeX\ACBrNFSeXServicos.ini"
A cidade São Carlos / SC que estava:
[4216008] Nome=Sao Carlos UF=SC Provedor=Betha o correto é:
[4216008] Nome=Sao Carlos UF=SC Provedor=IPM
 
A Cidade de Nonoai / RS que estava
[4312708] Nome=Nonoai UF=RS Provedor=DataSmart Versao=2.02 Params=AliasCidade:NONOAIRS o correto é:
[4312708] Nome=Nonoai UF=RS Provedor=DataSmart Versao=2.02 Params=AliasCidade:NONOAI
 
O Provedor IPM para a cidade de são carlos, está retornando o sucesso como '00001 - Sucesso'
para ter o correto envio da NFSe para este provedor fiz o seguinte ajuste na unit:
ACBr\trunk2\Fontes\ACBrDFe\ACBrNFSeX\Provedores\IPM.Provider.pas - Linha 280
Adicionando o "if ((Codigo <> '00001') and (Codigo <> '00001 - Sucesso')) then", pois caso não haja essa condição gera um erro como "Sucesso", pode verificar na imagem abaixo também.
procedure TACBrNFSeProviderIPM.ProcessarMensagemErros( RootNode: TACBrXmlNode; Response: TNFSeWebserviceResponse; const AListTag, AMessageTag: string); var I: Integer; ANode: TACBrXmlNode; ANodeArray: TACBrXmlNodeArray; AErro: TNFSeEventoCollectionItem; aMsg, Codigo: string; begin ANode := RootNode.Childrens.FindAnyNs(AListTag); if (ANode = nil) then ANode := RootNode; ANodeArray := ANode.Childrens.FindAllAnyNs(AMessageTag); if not Assigned(ANodeArray) then Exit; for I := Low(ANodeArray) to High(ANodeArray) do begin Codigo := ObterConteudoTag(ANodeArray[I].Childrens.FindAnyNs('codigo'), tcStr); aMsg := ACBrStr(ObterConteudoTag(ANodeArray[I].Childrens.FindAnyNs('Mensagem'), tcStr)); { Codigo = 00001 significa que o processamento ocorreu com sucesso, logo não tem erros. } if ((Codigo <> '00001') and (Codigo <> '00001 - Sucesso')) then begin AErro := Response.Erros.New; AErro.Codigo := Codigo; AErro.Descricao := aMsg; AErro.Correcao := ''; end; end; end;

Estava tentando utilizar o ACBR Monitor Plus, pois não sabia que seria possível usar os componentes ACBR dentro da minha DLL.
Estava sofrendo com as dependencias de Forms, Graphics e controls dentro da minha aplicação.
O problema foi meu aqui mesmo, vi que podemos usar direto os componentes ACBr mesmo na DLL, há como remover estas dependencias utilizando uma diretiva na compilação, por exemplo na unit ACBrSocket.pas que tem:
Uses math, StrUtils, synacode, ACBrUtil.Base, ACBrUtil.Strings, ACBrUtil.XMLHTML, synautil {$IFDEF UPDATE_SCREEN_CURSOR} ,Controls, Forms {$ENDIF}; e já está previsto que se não quiser fazer o uses, podemos colocar a diretiva na compilação NOGUI que já faz o undef
{$IFDEF NOGUI} {$UNDEF UPDATE_SCREEN_CURSOR} {$ENDIF} Isso resolveu o meu problema, já estava previsto por vocês.

O problema era no evento ACBrTEFDPayGoWebObtemCampo
 
Deve haver o onlynumber quando há solicitação da DLL para valores, no meu caso estava retornando virgula, e estava abortando o processo ou não encontrando a venda
o código abaixo resolveu o problema.
      if (AForm.TipoCampo = tcoCurrency) then  // PayGoWeb não precisa de ponto decimal
        Resposta := OnlyNumber(Resposta);