marciost

Italo, temos aqui sistemas para várias áreas e uma das maneiras de centralizar a parte de NFS-e e evitar retrabalho foi desenvolver um framework e compartilhar entre os vários sistemas. As coisas que são específicas de cada cliente tratamos numa tela de configuração. Nesse caso é uma situação específica do cliente, o padrão é assinar, mas esse cliente optou por não assinar, então ele mesmo gera o arquivo e importa no site. Por isso que eu preciso de acesso para escrever na propriedade, porque dai coloco isso numa configuração. O sistema lê as configurações do arquivo padrão, mas se tiver algo específico no cliente ele muda na configuração e via programação eu atualizo a opção. Essa era a ideia

Italo, são dois casos: envio via webservice e geração de arquivo Para gerar o arquivo eu uso o método GerarLote, mas o problema é que nesse cliente o lote não pode ser assinado porque ele não tem certificado digital. Só que eu não posso mudar a configuração do DBSeller.ini e informar para não assinar porque dai ocorre erro no cliente que envia via webservice, que precisa assinar. E por causa do jeito que foi implementado, não posso usar um arquivo DBSeller.ini por cliente, o arquivo é enviado junto como o exe como um recurso, então vai o mesmo para todo mundo. Por isso que acho que a solução é tornar a propriedade write, assim posso mudar via configuração externa.

Pessoal, boa tarde. Olha a situação: - temos o caso de dois clientes que são da mesma cidade (Sapiranga - Provedor DBSeller) - um deles envia o lote via webservice e assina XML - o outro cliente apenas gera o lote, sem assinar, e importa manualmente no sistema da Prefeitura O problema é a configuração do DBSeller: ou configuro para assinar e funciona no primeiro cliente, ou retiro a configuração e funciona no segundo. Eu tentei mudar a configuração via programação, mas NFSe.Configuracoes.Geral.ConfigAssinar.Lote é somente leitura. Não poderiam colocar o write na propriedade NFSe.Configuracoes.Geral.ConfigAssinar?

Obrigado Italo Atualizados os fontes e testado. Está OK

Italo, aproveitando: Estou tentando Itajaí/SC, e pelo menos aqui para mim o endereço https://nfse-teste.publica.inf.br/itajai_nfse_integracao/Services não funciona, tenho que colocar sem o HTTPS: http://nfse-teste.publica.inf.br/itajai_nfse_integracao/Services Isso está no arquivo do provedor, Publica.ini.

Pessoal, bom dia. Percebi durante meus testes que nos exemplos a URL de homologação da NFS-e de Santana do Livramento/RS está desatualizada: Como está: http://nfe.homologacao.sdolivramento.com.br Como deve ser: http://hom.nfe.sdolivramento.com.br/webservice/index/homologacao Então, deixo aqui para que posso atualizar.

Acho que vou colocar como resource do projeto então Por hora acho que pode ser encerrado esse tópico.

Felipe, mas nem é essa a dúvida. Eu queria saber se era normal ter que colocar todas essas DLL manualmente ou se tem como automatizar isso pelo componente. O problema é que são vários clientes e cada cliente com várias estações de trabalho.

Pessoal, até o momento estávamos utilizando a Capicom para assinar os XMLs da NFS-e. Mas por causa de problemas em alguns provedores, mudamos para a WinCrypt. Mas agora ao abrir o executável pede várias DLLs, exemplo: iconv.dll, libxml2.dll, libxmlsec.dll, libxslt.dll e zlib1.dll Isso está normal? Fiz tudo certo?

OK, Italo Acho que isso encerra o assunto.

Italo, foi testado na cidade de Guaiba/RS. Mas pelo que vi é sempre o mesmo, a recepção de lote de RPS também (RecepcaoLoteRPS=https://producao.ginfes.com.br/ServiceGinfesImpl)

Boa tarde O link para acesso à nfse do provedor ginfes não está funcionando corretamente. Segue anexo com o arquivo ajustado GINFES.ini

Pessoal, fui implementar envia pelo provedor Abaco num cliente de Canoas/RS e ocorria esse erro: "Erro não especificado" Pesquisando, vi que o motivo era por estar usando como identificador da assinatura o atributo 'id', mas no processo de assinatura é procurado o atributo 'Id', com o 'i' maiúsculo. Alterei no Abaco.xml para que fosse usado 'Id' ao invés de 'id', até assinou, mas ocorreu erro porque no schema está definido como 'id'. E pelo que vi nas minhas pesquisas não adianta alterar nos schemas, porque dai o erro ocorreria no webservice. Decidi então retirar o identificador, deixando vazio no arquivo Abaco.ini Fazendo isso o envio ficou correto, não tive mais problemas. Minha dúvida: alguém mais conseguiu essa solução? Ela é correta? Se sim, então podem ajustar no provedor o arquivo Abaco.ini?

Pessoal, trocamos a pouco tempo para o trunk2 do ACBrNFSe e percebemos que os arquivos de envio e retornos não são mais colocados dentro da pasta 'Ger'. Pesquisando vi que realmente foi retirado... Até não seria problema, mas do jeito que está agora parece que tem alguma configuração errada. Optamos por gerar o 'path mensal', ou seja, os arquivos são agrupados por mês e ano. Só que esses arquivos de envio e retornos que antes era colocados na Ger agora são todos colocados dentro do diretório base. Exemplo, se o diretório de arquivos for 'C:\XML', o componente cria dentro dele o diretório mensal 201806, e dentro do diretório 201806 os diretórios Notas e Recibos. Mas os arquivos de envio e retornos não ficam dentro do diretório mensal 201806, eles ficam todos dentro de C:\XML. É assim mesmo ou estou configurando algo errado?

Pode ser encerrado, foi constatado que é problema na PROCEMPA.

Pessoal, hoje estou tento o erro Arquivo enviado com erro na assinatura ao cancelar NFS-e. O estranho é que não mudou nada na geração do XML, inclusive arquivos de dias anteriores foram cancelados sem problema. Alguém mais está com esse erro?

Bom dia Italo Dei o exemplo do provedor IPM porque foi por causa dele tivemos que passar a alimentar separadamente o DDD e o Telefone, mas depois que fizemos isso começou a ocorrer erro no BHIss, que é ABRASF, e onde deve ir tudo junto no campo telefone. Nesses provedores que não tem separação temos que concatenar, porque o componente de carregamento dos dados permite carregar separado. Assim, se o DDD e o Telefone forem carregados separados, mas o provedor não tem DDD, a concatenação teria que ocorrer no componente, ao gerar a tag Telefone. Se o usuário deixou o DDD vazio e colocou tudo no Telefone, então não tem problema em concatenar, vai concatenar com o DDD vazio. O que eu acho que não pode ser feito é na aplicação eu ficar controlando qual é o provedor, porque o legal do componente é justamente abstrair isso. Sem contar que em algumas cidades o provedor muda, se não me engano esse provedor IPM substituiu o DBSeller, e dai começou o problema do DDD.

Ítalo, provedor IPM, se não me engano. Mas muda no componente... Se a pessoa separou DDD e Telefone dai não tem problema concatenar. Se colocou completo no Telefone, vai funcionar também...

Ítalo, não posso fazer isso porque o sistema é usado em várias cidades. Se eu concatenar vai resolver para POA, mas tem outra cidade que precisa enviar o DDD separada, não lembro qual, e que vai dar erro. O certo é o componente concatenar DDD + Telefone nos provedores que não tem DDD. Porque dai funciona sempre... porque nunca vai existir alguém que preencha o telefone completo na propriedade Telefone (ddd + fone) e também o DDD.

Constatei que alguns provedores tem nos dados de contato do tomador o telefone e outros o ddd e o telefone. No mapeamento das classes tem os campos DDD e Telefone e aqui passamos separadamente. Para os provedores que tem XML com DDD e Telefone fica correto, mas por exemplo o provedor BHIss tem somente telefone, e pelo menos em POA eles estão retornando com erro, pois acusa não ter o DDD. Então ajustei o componente para que nos provedores que tem somente a tag Telefone o sistema concatene junto o DDD. Testei e ficou correto. pnfsNFSeW_ABRASFv1.pas pnfsNFSeW_ABRASFv2.pas

Constatei que existe um erro na geração do XML de cancelamento para o provedor Abaco, na parte que gera as tag de início e fim. N tag de início existe um case e o provedor Abaco está nele, faz um validação específica para o município de Manaus e no else vai os demais. Só que essa tag inicial não está sendo montada em sincronia com a final. Na final são colocadas as tags </InfPedidoCancelamento> e </Pedido>, e na inicial não. No case da inicial, ele trata alguns provedores, e caso não seja um desse provedores então entra no else. E é esse else que monta corretamente a tag inicial. Não sei porque tem essa validação para Manaus, não retirei, mas pelo jeito não precisa. Deixo em anexo meu arquivo para que vejam e decidam o que é melhor fazer. Eu estou testando com o município de Canoas/RS. ACBrNFSeWebServices.pas

Ricardo, estou com o mesmo problema. Alias, não sei se percebeu, mas esse XML de envio está inválido, o componente não está montando ele corretamente. Veja que existe o fechamento das tags </InfPedidoCancelamento> e </Pedido>, mas não tem a abertura. Entretanto, mesmo ajustando aqui no componente e gerando o XML correto, o erro permanece. Para mim é o Abaco que está com problema na validação.

Beleza, já baixei as atualizações. Obrigado.

Pessoal, o provedor Tecnos retorna o link da NFS-e já no XML de notas, então ajustei o leitor para que esse conteúdo seja lido e passado para a nota. Fiz também um ajuste no processamento do retorno de consulta de lote desse provedor, que estava alterando indevidamente o número do protocolo. Deixei tudo que alterei comentado explicando o motivo da alteração. Em anexo os arquivos, não sei se coloquei as alterações no padrão e local correto, qualquer coisa podem ajustar. Tudo foi bem testado e está funcionando. ACBrNFSeWebServices.pas pnfsLerListaNFSe.pas pnfsNFSeR.pas

Boa tarde Houve alteração do provedor no município de Alvorada/RS de DBSeller para IPM. Eu fiz os ajustes e testei. Aproveitei e fiz uma alteração na parte de leitura do retorno, passando a pegar o link da NFS-e que já vem no próprio retorno. Em anexo os arquivos que alterei. ACBrNFSeWebServices.pas Cidades.ini pnfsEnvLoteRpsResposta.pas pnfsNFSe.pas