bsoft

Com a adesão do RJ à GNRE, há uma situação que precisa ser contemplada. Com o cód. receita 10030, é possível enviar o Valor Principal e o FCEP, ou apenas o FCEP. Nesta última situação o ACBr não está gerando a tag valorGNRE, ocasionando erro de validação. Segue em anexo a sugestão de correção para que o total seja preenchido corretamente no XML quando apenas o FCEP for informado. pgnreGNREW.pas

Perdão, esquecemos de anexar o arquivo fonte que foi modificado foi na unit ACBrGNREGuiasRetorno.pas ACBrGNREGuiasRetorno.pas

Identificamos dois problemas na impressão da GNRE v2.00. 1. NumDocOrigem deveria ler todos, não só do tipo "10". 2. InfoComplementares -> atualmente lê das tags "informacoesComplementares" e "campoExtra", concatenando os valores. O problema é que algumas UFs retornam a mesma informação, que foi enviada no "campoExtra", em ambas as tags. Na impressão a informação fica repetida. E outras UFs somente retornam na tag "informacoesComplementares". A alteração proposta para corrigir foi adicionar a string somente se ela não existir no "informacoesComplementares". Também foi adicionad

Aqui é a alteração que ficou faltando. Segue em anexo o mesmo arquivo, desfazendo as correções de indentação. ACBrMDFeDAMDFEFR.pas

Verificamos que a versão que anexamos aqui na primeira mensagem não foi exatamente a mesma que foi commitada na revisão 20492. Tudo bem que a maioria das alterações que foram descartadas são apenas ajustes de indentação, mas na unit ACBrMDFeDAMDFEFR.pas, ficou de fora a alteração para String dos campos no cdsModalAereo, na procedure CriarDataSetsFrx, que é essencial para o funcionamento correto. Por favor, pedimos que reavaliem o arquivo citado.

Pessoal, estamos atualizando o nosso sistema para a GNRE 2.0, e identificamos algumas correções necessárias para se fazer no ACBr. As três primeiras modificações do pgnreGNREW.pas são para evitar o preenchimento incorreto de tags que não são obrigatórias, similar ao que é feito na função GerarXML1. A última é relacionada com a tag valorGNRE, onde criamos uma property na pgnreGNRE.pas com este nome para informar o total de serviços. Hoje é enviado ou o campo c06_valorPrincipal ou o campo c10_valorTotal na tag valorGNRE. Porém, se for informado também o campo ValorFECP, será retornado o erro

Pessoal, gostaríamos de contribuir com um ajuste na emissão de MDF-e Aéreo, para o preenchimento correto das tags "nac" (Marca da Nacionalidade) e "matr" (Marca de Matrícula). Atualmente elas estão definidas como Integer, mas na verdade são códigos alfanuméricos, e seguem a expressão regular ER35, igual aos demais campos deste grupo, conforme a página 24 do Layout v3.00a. Um explicação de como funciona na prática estas informações pode ser encontrada na Wikipédia: https://pt.wikipedia.org/wiki/Prefixo_aeronáutico Segue em anexo as modificações necessárias (só não testamos com a imp

Boa noite, Ítalo Vimos que você commitou este arquivo aqui, ACBrCTeWebServices.pas, que foi anexado neste tópico na revisão 18495 do Trunk2, mas ficou faltando algo bem importante: na segunda chamada para o procedimento SalvarEventos, no else, não está sendo verificada a configuração do Arquivos.Salvar, gerando assim uma pasta "Docs" com o "-procEventoCTe.xml" a cada emissão, por mais que esteja tudo desabilitado no salvamento de arquivos. Segue em anexo a sugestão de correção com o arquivo já atualizado para a revisão 18566. Obs: o histórico no SVN da revisão 18495, "Removido d

Na sexta-feira, dia 11/10, enviamos a seguinte consulta para a SEFAZ de SP através do Fale Conosco (https://www.fazenda.sp.gov.br/email/default_nfe_cte.asp) : E hoje obtivemos a seguinte resposta: Portanto, está confirmada a mudança na regra no uso do SVC-SP.

Com certeza eles alteraram. Até a validação em ambiente de homologação do link do QRCode passou a acontecer no dia 18/09, mas não duvido que eles tenham "esquecido" da contingência, e resolveram mudar a regra neste meio tempo. Mas é fato que agora não dá para emitir pro SVC-SP enviando link para o homologacao.nfe.fazenda.sp.gov.br ... e só temos que lamentar a falta de transparência por parte deles de não anunciarem esta mudança.

Boa noite, Italo! Desculpe a demora na resposta, não tive tempo de lidar nisso durante o dia de hoje. E negativo: fiz um teste usando um certificado de MG, e recebi rejeição quando tentei enviar para o SVC-SP preenchendo o link do QR-Code com o endereço de SP: <qrCodCTe><![CDATA[https://homologacao.nfe.fazenda.sp.gov.br/CTeConsulta/qrCode?chCTe=31191003169658000110570040000003158002431302&tpAmb=2]]></qrCodCTe> 851-Rejeição: Endereço do site da UF da Consulta via QR Code diverge do previsto Em compensação, enviando o mesmo CT-e para o SVC-SP preenchendo o

A sugestão do @Eduardo Vismara atendeu corretamente a situação do MS (e legal que já está tratando para o PR, MG e MT), mas fazendo testes de emissão em Contingência para UF's que emitem normalmente para o SVRS - e que portanto enviam a contingência para o SVC-SP - continuamos recebendo a rejeição 851 - Endereço do site da UF da Consulta via QR Code diverge do previsto. Para resolver, complementamos a alteração do Eduardo assim: if ( (TipoEmissao in [teSVCRS]) and (CUF in [31,41,50,51]) ) or (TipoEmissao in [teSVCSP]) then Claro, todos os testes foram feitos em Homologação, e por e

Gostaríamos de reforçar o pedido da @flaviageisler e do @marcioereno de colocar em produção esta alteração. Entendemos bem o argumento que os campos não estão marcados como obrigatórios no manual, mas não há nenhum efeito negativo em mandar esta informação - não lembramos de ter visto a SEFAZ recusar algum documento fiscal por ter sido enviada uma informação que não era obrigatória. Analisando a sugestão de alteração do @marcioereno, ele acabou inutilizando a verificação dos percentuais igual a 0 (if (nfe.Det.Imposto.ICMS.pICMS = 0) and (nfe.Det.Imposto.ICMS.pDif = 0) then), então estamos

Apenas atualize os arquivos ACBrNFeServicos.ini e ACBrNFeServicos.rc da pasta ACBr\Fontes\ACBrDFe\ACBrNFe e recompile seu programa.

Prezados, Com a ativação do SVC para as emissões em MG no ambiente de Produção, o servidor SVC-SP está gerando o seguinte retorno: --------------------------- Versão Layout: 3.00 Ambiente: 1 Versão Aplicativo: SP-CTe-28-05-2019 Status Código: 113 Status Descrição: Serviço SVC em operação. Desativação prevista para a UF em 01/08/2019 às 12:00 horas UF: MG Recebimento: 30/07/2019 15:19:58 Tempo Médio: 1 Retorno: Observação: --------------------------- Este código de retorno, 113 - Serviço SVC em operação, não é esperado na função TCTeStatusServico.TratarResposta da ACBrCTeWebServ