Ir para conteúdo
  • Cadastre-se

bsoft

Membros
  • Total de ítens

    86
  • Registro em

  • Última visita

  • Days Won

    4

bsoft last won the day on 31 Dezembro 2017

bsoft had the most liked content!

Reputação

81 Excelente

3 Seguidores

Sobre bsoft

  • Rank
    Membro
  • Data de Nascimento 11-06-2006

Contact Methods

  • Website URL
    www.bsoft.com.br

Profile Information

  • Sexo
    Indefinido
  • Localização
    Ponta Grossa

Últimos Visitantes

1.156 visualizações
  1. Identificamos algumas correções necessárias na unit "ACBrEFDBloco_B_Class.pas" para geração do Bloco B: - Os campos de Valor do Registro B020 são obrigatórios (removido o True para permitir que venha null); - O segundo campo do Registro B440 (IND_OPER) deve ser preenchido com 0 ou 1, sem decimais (o manual está errado); - Ficou faltando o preenchimento do campo VL_SUB do Registro B470. Segue em anexo o arquivo para avaliação. ACBrEFDBloco_B_Class.pas
  2. Sim, verificamos em todos os fontes do ACBr, o uso é exclusivo no DACTE.
  3. Então, @Italo Jurisato Junior , pesquisando nos fontes do ACBr, as únicas units que fazem referência a esta função são estas: Fontes\ACBrDFe\ACBrCTe\DACTE\Fast\ACBrCTeDACTEFR.pas Fontes\ACBrDFe\ACBrCTe\DACTE\Fortes\ACBrCTeDACTeRLRetrato.pas Fontes\ACBrDFe\ACBrCTe\DACTE\Fortes\ACBrCTeDACTeRLRetratoA5.pas Apesar de ser uma função genérica, ela não é usada no DANFE. Uma alternativa para isso seria transferir esta função para a unit pcteConversaoCTe.pas, específica do CT-e, o que acha? Se concordar, podemos realizar esta alteração.
  4. Estamos enviando em anexo uma sugestão de mudança bem pequena, praticamente insignificante, mas que gerou transtorno para um dos nossos clientes. No manual do CT-e versão 3.00, página 165, foi removido o termo "anteriormente" da descrição da tag CST, dentro do grupo ICMS60. Obs: este procedimento CSTICMSToStrTagPosText é usado apenas nas impressões de DACTE. Segue em anexo a unit pcnConversao.pas com a modificação mencionada. pcnConversao.pas
  5. @anderson.mendonca, este erro é apenas falta de atualização dos Schemas da NF-e. Basta atualizar para a última ("Esquemas XML NF-e - Pacote de Liberação No. 9 (Novo leiaute da NF-e, NT 2016.002 v.1.60 - b). Publicado em 02/07/2018"), disponível no site da SEFAZ.
  6. Na versão 3.00 do CT-e, o campo nDoc do grupo idDocAntPap foi alterado para tipo Caractere de tamanho 30, porém no ACBr continua como inteiro. Segue a alteração para string de 30 para avaliação. ACBrCTeConhecimentos.pas ACBrCTeDACTEFR.pas pcteCTe.pas pcteCTeR.pas pcteCTeW.pas
  7. Atualizamos recentemente o ACBr depois de ficar quase 2 meses sem fazer isso, e constatamos um problema semelhante ao que muitos aqui estão relatando nos últimos dias aqui no Fórum, erro 12175 na consulta do Status do WS. Nós sempre usamos WinINet, setado em design. Pelo que verificamos, o problema surgiu na revisão 15267 realizada pelo DOPI, onde foi corrigido um erro de access violation ao usar a propriedade TimeOutPorThread como True. Porém, esta alteração fez com que, no momento da criação do componente, a inicialização do TACBrWinINetReqResp nunca seja chamada, porque no constructor do TDFeHttpWinHttp, o ADFeSSL.SSLHttpLib ainda está como httpNone, caindo no create do TACBrWinHTTPReqResp. Uma solução é habilitar o TimeOutPorThread, porque isso faz com que a cada criação da Thread, a inicialização do TACBrWinINetReqResp seja chamada. Mas para quem ficar com o TimeOutPorThread = False e httpWinINet setado em design, enfrentará problemas. Como sugestão para resolver o problema, e mantendo a correção do access violation que o DOPI fez, sugerimos mudar a atribuição do FSSLHttpLib := ASSLHttpLib; para antes do case. Assim, no momento do Create, o httpWinINet já estará setado e fará a inicialização correta. Segue em anexo a unit ACBrDFeSSL.pas com a correção sugerida. @Daniel Simoes, poderia por favor dar uma verificada? ACBrDFeSSL.pas
  8. Encontramos um erro na impressão da Guia da GNRE no campo "Período de Referência" em Fast Report. Está sendo impresso somente o código da referência, ex."0" sem constar a data. Pelo que foi verificado, a impressão em Fortes já está correta. Segue a correção para Fast. GNRE_GUIA.fr3 ACBrGNREGuiaFRDM.pas
  9. Favor validar novamente. ACBrUtil.pas
  10. Emitir um CT-e com observação contento aspas. Ex.: Observação no conhecimento "de" número 99999 No DACTe será impresso conforme o print abaixo. O mesmo também vai acontecer na DANFE para as informações complementares.
  11. bsoft

    Geração da chave de NF-e Avulsa

    Foi feita uma alteração na geração da chave de acesso ao gerar o XML da NF-e (autoria do @Italo Jurisato Junior na revisão 14691), que causa erro na geração de chave de NF-e Avulsa, na qual o CNPJ informado na chave de acesso é diferente do CPF/CNPJ do emitente. Segue o arquivo com a reversão do trecho de código em questão. pcnNFeW.pas
  12. Tivemos problemas na impressão da observação no DACTe devido à função AddDelimitedTextToList que é usada pela Split. Foram colocadas aspas para resolver o problema de quebrar nos espaços em branco, porém isso dá erro caso haja aspas na observação preenchida pelo cliente. Segue a proposta para correção, foi alterado somente a parte para Delphi que não tem suporte à propriedade StrictDelimiter do StringList. Testado no Delphi 10.1 e no Delphi 7. ACBrUtil.pas
  13. Estamos enviando alterações na unit "ACBrEPCBloco_C_Class.pas" para que os campos VL_BC_IPI, ALIQ_IPI, VL_IPI do Registro C170 não sejam preenchidos na geração do arquivo quando não houver valores de IPI , ao invés de preencher com "0,00" como é feito hoje. Segundo o Guia Prático, esses campos não são obrigatórios. Segue para avaliação. ACBrEPCBloco_C_Class.pas
  14. bsoft

    CTe TLS 1.2

    @MarceloPeron, também recebemos esta mensagem da SEFAZ do MS, e pelos nossos primeiros testes, é necessário setar a propriedade SSLType com o valor LT_TLSv1_2. uses blcksock; ... ACBrCTe.SSL.SSLType := LT_TLSv1_2; Com nenhuma outra opção desta propriedade funcionou a comunicação com o ambiente de Homologação de CT-e do Estado do MS. Hoje esta propriedade é definida por padrão como LT_all, isso provavelmente terá que ser alterado para LT_TLSv1_2, só não conseguimos testar/confirmar o impacto desta alteração antes dessa mudança definitiva da SEFAZ.
  15. @elisangela carla, o problema é o código errado do tpEmis, note que no teu XML você informou 7 ao invés de 8. O correto para a emissão em contingência para o Estado de Santa Catarina (cUF = 42) é 8, deve ser enviado para o SVC-SP. Essa relação está disponível na Nota Técnica 2012.003 (ao invés de colocarem esta informação no manual 3.0.... praticidade é com a SEFAZ ) @darlananogueira, as tags dhCont e xJust só são necessárias na emissão em contingência offline FS-DA (tpEmis = 5), conforme as rejeições 586 e 587.
×
×
  • Criar Novo...