Jump to content
Notícias do ACBr

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

consultoria_sticker.png

Conteúdo para desenvolvedores
 ao vivo de terça a quinta!
Saiba mais

dev.png

logo_acbr_paygo.png

TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


botao.png

beneficios.png

bsoft

Membros
  • Content Count

    102
  • Joined

  • Last visited

  • Days Won

    4

bsoft last won the day on December 31 2017

bsoft had the most liked content!

Community Reputation

101 Excellent

5 Followers

About bsoft

  • Rank
    Membro
  • Birthday 06/11/2006

Contact Methods

  • Website URL
    www.bsoft.com.br

Profile Information

  • Sexo
    Indefinido
  • Location
    Ponta Grossa

Recent Profile Visitors

1,961 profile views
  1. 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
  2. Perdão, esquecemos de anexar o arquivo fonte que foi modificado foi na unit ACBrGNREGuiasRetorno.pas ACBrGNREGuiasRetorno.pas
  3. 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
  4. Aqui é a alteração que ficou faltando. Segue em anexo o mesmo arquivo, desfazendo as correções de indentação. ACBrMDFeDAMDFEFR.pas
  5. 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.
  6. 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
  7. 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
  8. 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
  9. 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.
  10. 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.
  11. 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
  12. 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
  13. 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
  14. Apenas atualize os arquivos ACBrNFeServicos.ini e ACBrNFeServicos.rc da pasta ACBr\Fontes\ACBrDFe\ACBrNFe e recompile seu programa.
  15. 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
×
×
  • Create New...