simons

ola, minha sugestão para esse problema em anexo, se ajudar poste o resultado aqui, e ai quem sabe teremos no repositório a alteração. ACBrNFeNotasFiscais.pas

segundo contato com o provedor o envio é sincrono e não envia lote so o rps, alguma idéia de ajuste?

então no envio de rps recebo a mensagem: A funcionalidade [Enviar Lote] não foi disponibilizada pelo provedor: TcheInfov2 olhando os fontes não consegui entender muito mas vi que tem uma configuração no arquivo ini chamada [SoapAction] Recepcionar=* e ela esta com o asterisco é por isso que nao esta enviando? se sim oque vai nesta configuração?

Fiz isso, porem usei como base o provedor Bethav2.ini, mas ai na hora de testar acontece erros que nao sei corrigir, mas posso anexar aqui sim as alteracoes. segue em anexo. pnfsConversao.pas Cidades.ini TcheInfov2.ini nfse_v202.xsd

Ola colegas! preciso configurar um novo provedor no acbr e não sei como fazer, é padrao abrasf V2. Municipio Santo Antonio do Planalto/RS codigo: 4317756 endereco de homologação: https://homologacao-nfse.tcheinfo.com.br/TcheNFSePortal/servlet/com.tche.nfse.anfsewebservice?wsdl producao: https://nfse.tcheinfo.com.br/TcheNFSePortal/servlet/com.tche.nfse.anfsewebservice?wsdl Schema: http://www.abrasf.org.br/arquivos/publico/NFS-e/Versao_2.04/nfse_v2-04.xsd Nome do provedor: TcheInfo não sei se precisa de mais alguma coisa...

Ola, imagino que se nao informar o valor da mora juros e nem data de mora juros o proprio componente deve colocar esse codigo de mora como 3. se olhar esse trecho de codigo no metodo geratransacao240: IfThen( (ValorMoraJuros > 0) and (CodigoMora= ''), '1', PadRight(CodigoMora, 1, '3') ) + //118 - Código de juros de mora: Valor por dia vera que se nao informar o valor da mora juros vai como isento na remessa.

Ola Colegas, ao enviar email da NFe na sequencia envio outro email dos boletos, até ai tudo bem, porém se eu não sair da tela do sistema e tentar enviar novamente email de uma nota tenho o erro de Unable to Login, se eu sair da tela e entrar novamente tudo normal de novo posso fazer outra nota e enviar por email, detalhe com pdf em anexo... uso email do gmail, tentei ja com TLS porta 587 , tentei com SSL porta 465 sem sucesso. aguém sabe como posso resolver esse problema?

Olá, não tenho certeza mas tipo se eu sair da tela e entrar novamente funciona, agora se eu mandar email pelo acbrnfe e em seguida pela acbrboleto na primeira vez funciona na segunda sem sair da tela da esse erro.

essa é a mensagem exata do problema.

Ola Colegas, reabrindo o topico, estou com o seguinte problema: ao enviar email da NFe na sequencia envio outro email dos boletos, até ai tudo bem, porém se eu não sair da tela do sistema e tentar enviar novamente email de uma nota tenho o erro de Unable to Login, se eu sair da tela e entrar novamente tudo normal de novo posso fazer outra nota e enviar por email, detalhe com pdf em anexo... uso email do gmail, tentei ja com TLS porta 587 , tentei com SSL porta 465 sem sucesso. aguém sabe como posso resolver esse problema?

na imagem acima fica claro o que o homologador observou quando me enviou email. segue me anexo sugestão de alteração. ACBrBancoBanrisul.pas

na imagem acima fica claro o que o homologador observou quando me enviou email. a alteração ainda não fiz mas vou fazer então e postar aqui.

Ola, pelo que vi você usou a modalidade para testar se deve ou não preencher o campo nosso numero, porém esse campo é para dizer se o tipo de cobrança é reigstrada ou não, então não pode usar esse campo para essa finalidade, deve usar a variavel TipoBoleto = 'A' alimentando o campo ACBrBoleto.Cedente.ResponEmissao <> tbCliEmite ou CarteiraEnvio = tceBanco para que ai sim seja deixado em branco então o nosso numero.

Ola Colegas, em homologação hoje no banco banrisul aqui no RS, o arquivo de remessa passou, porém com uma obs. disendo que todos os campos numéricos não utilizados devem estar em branco e não zerados, layout cnab 400. alguém mais passou por isso já?

sim, mas o caso que estou fazendo é para notas com somente uma forma de pagamento e essa com tpag = 90 - sem pagamento, nesse caso o acbr rejeita por causa do teste que passei acima, então para resolver isso fiz a alteração.

Segue me anexo sugestão de alteração para resolver essas questões do uso do tipo de pagamento 90 sem pagamento, agora é aguardar alguem avaliar e enviar para o repositório. esse é o código alterado: if (NFe.Ide.modelo = 65) and (NFe.infNFe.Versao < 4) then begin GravaLog('Validar: 767-NFCe soma pagamentos'); fsvTotPag := 0; for I := 0 to NFe.pag.Count-1 do begin fsvTotPag := fsvTotPag + NFe.pag.vPag; end; if (NFe.Total.ICMSTot.vNF <> fsvTotPag) then AdicionaErro('767-Rejeição: NFC-e com somatório dos pagamentos diferente do total da Nota Fiscal'); end else if (NFe.infNFe.Versao >= 4) and ((NFe.Ide.finNFe = fnNormal) or (NFe.Ide.finNFe = fnComplementar)) then begin fsvTotPag := 0; NFTPagSemPagamento:=false; for I := 0 to NFe.pag.Count-1 do begin fsvTotPag := fsvTotPag + NFe.pag.vPag; if NFe.pag.tPag = fpSemPagamento then begin NFTPagSemPagamento:=true; end; end; //se houver uma forma de pagamento na nota com TPag = 90 não pode validar a soma nem o troco da NFe if not NFTPagSemPagamento then begin GravaLog('Validar: 767-Soma dos pagamentos'); if (fsvTotPag < NFe.Total.ICMSTot.vNF) then AdicionaErro('767-Rejeição: Somatório dos pagamentos diferente do total da Nota Fiscal'); GravaLog('Validar: 869-Valor do troco'); if (NFe.Total.ICMSTot.vNF <> (fsvTotPag - NFe.pag.vTroco)) then AdicionaErro('869-Rejeição: Valor do troco incorreto'); end; end; ACBrNFeNotasFiscais.pas

Mas você usa o método validarregrasdenegocios? Pois finalidade normal levantaria rejeição se não tiver a tal vpag maior que zero, você olhou o código que postei acima?

Cara você abriu um topico sobre o mesmo assunto que eu olhe no link: logo acima do teu.

acontece que voce deve atentar para o coidgo a seguir retirado do metodo validaregrasdenegocios do arquivo que passei no anexo anteriormente: if (NFe.Ide.modelo = 65) and (NFe.infNFe.Versao < 4) then begin GravaLog('Validar: 767-NFCe soma pagamentos'); fsvTotPag := 0; for I := 0 to NFe.pag.Count-1 do begin fsvTotPag := fsvTotPag + NFe.pag.vPag; end; if (NFe.Total.ICMSTot.vNF <> fsvTotPag) then AdicionaErro('767-Rejeição: NFC-e com somatório dos pagamentos diferente do total da Nota Fiscal'); end else if (NFe.infNFe.Versao >= 4) and ((NFe.Ide.finNFe = fnNormal) or (NFe.Ide.finNFe = fnComplementar)) then begin fsvTotPag := 0; for I := 0 to NFe.pag.Count-1 do begin fsvTotPag := fsvTotPag + NFe.pag.vPag; end; GravaLog('Validar: 767-Soma dos pagamentos'); if (fsvTotPag < NFe.Total.ICMSTot.vNF) then AdicionaErro('767-Rejeição: Somatório dos pagamentos diferente do total da Nota Fiscal'); GravaLog('Validar: 869-Valor do troco'); if (NFe.Total.ICMSTot.vNF <> (fsvTotPag - NFe.pag.vTroco)) then AdicionaErro('869-Rejeição: Valor do troco incorreto'); end; com minha mudança somente notas com finalidade devolucao ou ajuste poderao usar esse tpag = 90, se não colocar o valor na tag vPag que é oque diz a regra da NT v1.60 é que o problema acontecera em uma nota com finalidade Normal ou complementar, caso de transferencias, remessas etc. Ai é que esta o problema segundo a NT v1.60 não existe uma exceção para a rejeição 869 do troco, mas também não existe a rejeição validada pelo ACBrNFe numero 769.... as duas nesse caso são conflitantes, mesmo que retire a rejeição 769 e 869 acredito que não passaria na sefaz pela rejeição 869 do troco se a sefaz esta segundo o manual, até vou fazer um teste hoje retirando essa validação para ver se a sefaz ira validar ou não.

não pode informar valor na tag vPag quando tPag = 90, o detalhe é que isso só é valido para Finalidade da nota Ajuste ou Devolucao, se a nota for finalidade normal ou complementar não pode informar tPag = 90 eu estou informando 99 - Outras. Essa era minha duvida, como o pessoal do forum esta tratanto isso, pois penso que deveria tambem ser tPag = 90 - Sem pagamento, porém se olhar o manual não existe a regeição 767 que é a soma das formas de pagamento para esse caso mas a rejeição 869 que é referente ao troco sim, ou seja uma regra interfere na outra e não tem a exceção para essa ultima rejeição 869.

creio que essa alteracao em anexo resolva o teu problema nas devolucoes pois eu chequei a finalidade da nfe se for normal ou complementar ai sim ele fara a checagem o troco e forma de pagamento. @Darlan Souza. ACBrNFeNotasFiscais.pas

e mais, na verdade para finalidade de ajuste ou devolucao é obrigado ter o tipo pagamento codigo 90 sem pagamento ou seja para devolucao por exemplo isso ta no manual, teremos que ajustar essa validação.

bom dia, penso que seria o caso de seu sistema armazenar os dois campos e conforme a necessidade informar em um ou em outro a informacao do codigo da empresa, ou nos dois a mesma informacao.

Ola colegas! um cliente tentou fazer uma nota NF-e modelo 55 de remessa para conserto com o tipo de pagamento sem pagamento, ai recebi das regras de negocio do acbr a rejeição 767 - somatório dos pagamentos diferente do total da nota fiscal e tambem essa 869 - valor do troco incorreto, olhando a nota tecnica 2016_002 v1.60 so fala dessa regra 767 para modelo 65 e esta riscada de vermelho, e tambem ela diz que quando o tipo de pagamento for sem pagamento codigo 90 não pode ter valor de pagamento tag vpag deve ser zero e sobre a rejeição 869 pelo que vejo ela não preve esse tipo de pagamento pois ela exige que total das forma de pagamento - vNF seja o valor do troco mas não apresenta a exceção do tipo pagamento 90 sem pagamento. então não sei o que é correto e como estão fazendo esse tipo de nota, se estão colocando o tipo de pagamento como 99 outros ou outro tipo de pagamento? este tambem seria o caso das transferencias entre filiais ...

provavelmente na base de calculo do icms st deve ter o MVA margem de valor agregado, que não esta aparecendo nas tags por isso o valor da base é maior que a base do icms proprio e o valor do icms st é o calculo do valor do icms st - icms proprio ou seja, 605,81 * 25% = 151,45 - 100,38 = 51,07