simons

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

Se alguém passar por isso, resolvi o problema informando a unidade de medida como Décimo de milimetros ai funcionou, essa função nessa configuração não muda o valor que informei. obrigado mesmo assim.

Ola colegas! com a ultima atualização do ACBrETQ estou enfentando o seguinte problema na função ConverteUnidade do arquivo ACBrETQPpla: estou usando a unidade de medida Milimetros e configuro no meu sistema 5 milimetros por exemplo, porem essa função faz a conversao de 5 x 10 colocando o numero 50 e como ela so recebe numeros inteiros então não consigo informar 0,5 para que o resultado seja 5 milimetros assim dando problema na impressão da mesma. alguem esta passando por isso também? minha sugestão seria que o parametro aceitasse numero decimal para que eu pudesse infomrar 0,5 e ai sim a conversao colocaria 5 milimetros como eu quero.

Ola, segue em anexo uma sugestão de alteração para NF-e na função que testa as regras de negócio da NF-e pois ela não esta somando o vIPIDevol e vFCPST ao total da nota ai quando tem esses valores da erro, dizendo que nao fecha o valor total da nota. alguém pode analisar e subir essas alterações. Obrigado. ACBrNFeNotasFiscais.pas

ola, baixei do site esse novo pacote e tive problemas de rejeição na questão de alguns ncm que nao deixava informar a unidade de medida tributável compativel... então fui obrigado a voltar ao pacote antigo.

Incluido a Cidade Panambi/RS em Cidades.ini Provedor IPM, segue em anexo arquivo. Cidades.ini

assim, na prefeitura tem uma opcao para marcar quando o tomador ja tem cadastro la, ai o que acontece, se ele ja tiver cadastro la tem que marcar para nao usar as informacoes que passamos nas tags entende, pois a prefeitura quer checar a documentação para poder alterar o endereço na prefeitura, caso seja tomador novo ai sim tem que passar como sim nessa tag para que crie o cadastro na prefeitura .

ola, não é possivel, explico porque, esse provedor tem uma configuracao na prefeitura que diz que deve ser usado os dados de endereço do tomador que estao na prefeitura, porem quando é novo tomador ai eles aceitam o endereco entende? ai precisa tem esse campo para poder marcar ou desmarcar a opcao dependendo da prefeitura, e eles nem disponibilizam um webservice para consulta do cadastro para ver se ja ta cadastrado ou nao o tomador na prefeitura é complicado mesmo. se puder acrescentar essa campo agradeço muito.

Ola amigos, segue uma contribuição referente a citação acima por mim mesmo, com a solução referente ao metodo validarregrasdenegocios, espero que seja avaliado a alteração e incluida no repositorio. obrigado. ACBrNFeNotasFiscais.pas

Ola colegas, estudei os componentes do acbrnfse e fiz a alteração necessaria para funcionar essa questao acima, peço que avaliem minhas alterações e as incluam na proxima revisão. Muito obrigado. ACBr_NFSe.dpk pnfsNFSe.pas pnfsNFSeW_IPM.pas

Ola Pessoal, quem tem mais conhecimento dos fontes e utiliza o provedor IPM poderia incluir uma propriedade para poder escolher na hora da emissão se essa tag endereco_informado seja S ou N por favor?