João Paulo Müller
-
Total de ítens
326 -
Registro em
-
Última visita
-
Days Won
2
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por João Paulo Müller
-
-
Boa tarde, prezados.
Na importação do SPED quando está importando o registro C170 e o campo quantidade por algum motivo não for preenchido o sistema dispara uma exceção:
CitarCould not convert variant of type (null) into type (Double)
Verificando o código fonte identifiquei que para preencher o campo QTD do registro C170 está sendo utilizado a função ValorFV que retorna null caso a string estiver vazia, diferente dos demais campos float que é utilizado a função ValorF onde retorna 0 quando a string estiver vazia.
Defeito
QTD := ValorFV;Correção
QTD := ValorF;Segue em anexo unit com a correção.
Aproveitando o assunto, seria possível adicionar um tratamento de exceção para informar qual a linha que disparou erro na importação do SPED? Utilizando como exemplo esse caso que citei acima para eu identificar qual foi a linha que deu erro tive que depurar e levou um bom tempo, se tiver um tratamento de exceção que exibe a linha já ajudaria um bocado, mas seria só um complemento mesmo, acredito que corrigindo essa questão da QTD não ocorre mais problemas.
-
1
-
-
16 minutos atrás, Juliomar Marchetti disse:
Em que momento isso? na leitura do xml ou na criação?
favor anexar a alteração
Bom dia Juliomar.
É na leitura do XML.
Segue unit em anexo.pcnNFeR.pas
-
Olá Prezados,
Passei por algumas situações em que o componente preenche o nItem com o valor diferente do que realmente consta na TAG det.
Ao analisar o caso notei que no componente está sendo preenchido o nItem com uma ordem sequencial (I + 1), porém, acontece que há notas que são emitidas com o nItem fora dessa ordem.
Isso acaba trazendo problemas quando preciso identificar o nItem em algum documento/declaração, como por exemplo, o DRCST que inclusive na validação confronta o nItem da declaração com a tag det do XML.
Exemplo:
// 1° item da NFe <det nItem="10">
O componente vai preencher o nItem com 1 não 10.
Correção
A correção é simples, já havia feito aqui na minha maquina e estava utilizando por um tempo, porém, quando atualizo o ACBr sempre perco essa alteração, portanto, se fosse possível fazer a correção direta na lib ficaria agradecido.
Código atual:
NFe.Det[i].prod.nItem := i + 1;Correção:
NFe.Det[i].prod.nItem := nItem;Já existe uma variável (nItem) que obtém o valor correto da tag det, portanto, seria apenas utilizar essa variável.
-
Olá, pessoal.
Realizei uma alteração no componente incluindo a natureza 118 (no118) no arquivo pnfsConversao, pois Chapecó utiliza essa natureza: 118 - ISS retido pelo tomador - Devido para Chapecó (Simples Nacional).
Segue arquivo em anexo.
-
Olá pessoal.
Agronômica - SC trocou provedor de Betha para Publica.
Segue arquivos alterados em anexo.
-
Obrigado Italo.
-
Olá pessoal,
Estava com um problema para envio de NFs para o município de Blumenau quando cliente era do Simples Nacional
.
Notei que não estava sendo gerada a tag RegimeEspecialTributacao quando provedor é proSimplISSv2, porém, foi constado a necessidade de geração dessa tag também para esse provedor.
Ajustei essa alteração na unit pnfsNFSeW_ABRASFv2, linha 965:
// Código do repositório: if not (FProvedor in [proSigep, proiiBrasilv2, proSimplISSv2, proMegaSoft, proSiapSistemas]) then if NFSe.RegimeEspecialTributacao <> retNenhum then Gerador.wCampo(tcStr, '#6', 'RegimeEspecialTributacao', 01, 01, 0, RegimeEspecialTributacaoToStr(NFSe.RegimeEspecialTributacao), DSC_REGISSQN);Correção:
//Removido proSimpliisV2 if not (FProvedor in [proSigep, proiiBrasilv2, proMegaSoft, proSiapSistemas]) then if NFSe.RegimeEspecialTributacao <> retNenhum then Gerador.wCampo(tcStr, '#6', 'RegimeEspecialTributacao', 01, 01, 0, RegimeEspecialTributacaoToStr(NFSe.RegimeEspecialTributacao), DSC_REGISSQN);Segue em anexo unit com a alteração.
Desde já agradeço a atenção.
-
19 minutos atrás, Juliana Tamizou disse:
Boa tarde.
Existe alguma publicação oficial com mais detalhes sobre esses assuntos?
Relativo ao Bloco X seria somente para quem ainda vai iniciar a obrigatoriedade ou será que é valido para quem já está obrigado?
Att.
Boa tarde.
Não sei te dizer, recebi esse comunicado de uma acessória, mas vou ver se descubro algo e coloco aqui.
-
Prezados (as)
Hoje (25), o presidente do Sescon/SC juntamente com as demais entidades contábeis do Estado participaram da reunião com a SEFAZ para tratar da prorrogação da entrega do Bloco X.
Após manifestações das entidades e dos próprios representantes da SEFAZ a entrega foi prorrogada para o mês de março/2021. O ato oficial sairá no início da próxima semana.Além disso, foi tratado sobre a Nota Fiscal Eletrônica de Consumidor. A norma legal de implementação sairá nos próximos dias e as empresas terão três opções para aderir. A opção escolhida é que vai definir se a empresa deverá ou não entregar o Bloco X. A opção também vai até março/2021
Bom final de semana a todos.
-
5
-
-
2 minutos atrás, Italo Jurisato Junior disse:
Bom dia João,
Desde já muito obrigado pela colaboração, vou incluir na minha lista de tarefas e assim que possível vou analisar.
Bom dia Italo.
Eu que agradeço.
-
Olá pessoal,
Não sei se seria o caso de um novo tópico, vou por aqui mas caso for necessário registro um tópico novo.
Estou incluindo o suporte ao município de Canoinhas e percebi que na função StrToNaturezaOperacao da unit pnfsConversao não tem as strings de natureza '17' e '18', sendo que Canoinhas utiliza essas naturezas
Citar17 - ISS Retido pela Prefeitura de Canoinhas
18 - ISS Retido pela Prefeitura de Canoinhas (Simples Nacional)
Segue em anexo a unit pnfsConversao alterada com a inserção das natureza 17 e 18.
-
1
-
-
6 minutos atrás, Daniel Simoes disse:
Acho que está correto pois na linha seguinte o I é usando como Parâmetro de Entrada, mas também recebe o resultado
if (docElement <> '') then I := Pos('<'+docElement, AXML) else I := 1; I := PosEx(IdAttr+'=', AXML, I); // AQUI TEREMOS UM NOVO "I" if I = 0 then // XML não tem URI Exit;
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!
-
1
-
-
2 horas atrás, Daniel Simoes disse:
Mas acho que a correção, é mais simples..
if (docElement <> '') then I := Pos('<'+docElement, AXML) else I := 1; // AQUI
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?
-
11 minutos atrás, BigWings disse:
Tente alterar para:
A := ACBrDFE.Assinar(XML, 'Pedido', 'InfPedidoCancelamento');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.
-
1
-
-
1 hora atrás, BigWings disse:
Você está com os arquivos .ini atualizados junto com a versão atual da sua aplicação?
No arquivo Betha.ini deve conter o elemento a localizar no cancelamento:
Que parece correto de acordo com a imagem do XML.
Está dessa forma no seu .ini?
Boa tarde, @BigWings.
Em 05/05/2020 at 10:59, João Paulo Müller disse:OBS: Para esse municipio realizamos a contrução do XML manualmente e utilizamos o compontene ACBr apenas para realizar o envio e assinatura.
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) [...] -
Segue em anexo Unit alterada.
-
1
-
-
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!
-
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.
-
1 minuto atrás, Scandolara disse:
ola @João Paulo Müller , é duvida minha também ... O que fiz para tentar esclarecer para todos nós e inclusive pessoal do devel do ACBR, mandei um e-mail para Portal do MDFe do RS, o que é quem cuida do projeto MDFe, fazendo essa pergunta para os mesmos.
Tentei contato com a ANTT, mas infelizmente pessoal da ANTT esta mais perdido do que nós.
Estou aguardando o retorno da resposta desse questionamento que fiz para o pessoal do RS.
Assim que me retornarem vou colocar aqui.
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?
-
1
-
-
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.
-
1
-
-
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.
-
2
-
-
16 minutos atrás, brunomeida disse:
Obrigado meu querido :).
Ja faz duas semanas e eles nao me responderam.Funcionou certinho
Nas pesquisas que fiz, o Simpliss para blumenau possui apenas o ambiente de Produção.
Também vi isso aqui oh:
https://atendimento.tecnospeed.com.br/hc/pt-br/articles/360036915094-Documentação-Técnica-Padrão-BLUMENAUBoa 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).
-
1
-
-
4 horas atrás, Ernesto Ricardo disse:
Bom dia pessoal,
Sobre o cancelamento,
Estava fazendo testes com o Pedro. O XML retorna como se estivesse cancelado mas não cancela na prefeitura... Isso ocorre no WS 1. O Mesmo XML no WS normal cancelou. O Pedro já abriu uma solicitação para correção do WS 1 com a equipe de desenvolvimento deles... assim que ele me der um ok posto aqui.
Boa tarde Ernesto,
Esse defeito é em ambiente de homologação, produção ou ambos?
-
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=1Peço que se possível realizem a analise para subir essa alteração no SVN.
Grato!
Leitura Registro C800 - CFe SAT
em ACBrSPEDFiscal
Postado
Olá prezados.
Fiz um ajuste no registro C800 incluindo alguns campos que não estavam sendo importados no SPED.
Segue alteração e unit em anexo.
procedure TACBrSpedFiscalImportar_BlocoC.RegC800; begin with ACBrSpedFiscal.Bloco_C.RegistroC800New do begin COD_MOD := Valor; COD_SIT := StrToCodSit(Valor); NUM_CFE := Valor; DT_DOC := ValorD; VL_CFE := ValorF; VL_PIS := ValorF; VL_COFINS := ValorF; CNPJ_CPF := Valor; NR_SAT := Valor; CHV_CFE := Valor; end; end;ACBrEFDBloco_C_Importar.pas