Ir para conteúdo
  • Cadastre-se

Painel de líderes

Conteúdo popular

Showing content with the highest reputation on 30-04-2019 em todas as áreas

  1. Boa tarde a todos, Já esta disponível em nossa biblioteca a Nota Técnica 2019/001 que trata sobre novas regras de validação. Resumo da NT: · Dificultar utilização de código de segurança fraco · Melhorar o controle de documentos referenciados e da identificação do destinatário · Descrever benefícios fiscais e informações da tributação do ICMS com mais precisão · Criação de valor máximo para a base de cálculo do ICMS, por unidade federada · Melhor gerenciamento de informações sobre o destinatário, tanto no serviço de autorização de NF-e quanto no serviço de registro de EPEC Datas previstas para entrada em vigor: 01/07/2019 - Ambiente de Homologação; 02/09/2019 - Ambiente de Produção. Alterações no componente: Nenhuma, visto que essa NT trata de novas regras de validação a serem implementadas pelas SEFAZ-Autorizadoras. Novas Regras de Validação: Criada a Regra de Validação B03-10, para dificultar a utilização de um código de segurança fraco, ou seja, o valor de cNF não vai poder ser igual ao valor de nNF e sim um numero aleatório. Criadas regras de validação a documentos referenciados:  Regra de Validação BA10-40 foi alterada, possibilitando a utilização do CNPJ 8 (somente os 8 primeiros dígitos) com o objetivo de identificar que a nota foi emitida pelo mesmo contribuinte, a critério da unidade federada. Criada a Regra de Validação BA10-50, exigindo que uma contranota de produtor rural somente possa referenciar uma nota emitida por outro produtor rural, a critério da unidade federada. Criada a Regra de Validação BA20-20, impedindo que seja referenciado um documento fiscal de uso exclusivo para operações internas em uma operação destinada a outra unidade federada ou para o exterior. Criada a Regra de Validação BA20-30, impedindo referência a um Cupom Fiscal, a critério da unidade federada. Criadas regras de identificação do destinatário: Criada a Regra de Validação E03a-30, impedindo o uso simultâneo de IE e de identificação de estrangeiro para o destinatário. Criada a Regra de Validação E14-30, impedindo informação de país de destino “Brasil” em operações destinadas ao estrangeiro. Criada a Regra de Validação E16a-40, exigindo a indicação de “operação com consumidor final” quando se indica que a operação é destinada a não contribuinte. Criadas regras de validação tornando obrigatória a informação do Motivo da Desoneração e do Valor do ICMS desonerado, caso seja informado o Código do Benefício Fiscal: Criada a Regra de Validação I05f-10, impedindo a informação de um código de benefício fiscal juntamente com um CST que não prevê benefício fiscal, a critério da unidade federada. Criada a Regra de Validação I05f-20, impedindo a informação de um código de benefício fiscal que não corresponda ao CST utilizado, a critério da unidade federada. Criada a Regra de Validação I05f-30, exigindo que seja informado o valor do ICMS desonerado ou o motivo de desoneração quando se utiliza um código de benefício fiscal, a critério da unidade federada. Criada a Regra de Validação N07-10, exigindo informações sobre o diferimento quando se utiliza um CST de diferimento, a critério da unidade federada. Criada a Regra de Validação N12-84, exigindo o código de benefício fiscal quando se utiliza um CST de benefício fiscal, a critério da unidade federada. Criada a Regra de Validação N12-88, exigindo que o CST corresponda ao tipo de código de benefício fiscal informado, a critério da unidade federada. Criada a Regra de Validação N12-90, exigindo valor do ICMS desonerado e o motivo da desoneração, a critério da unidade federada. Criada a Regra de Validação N18-10, exigindo a informação do percentual da margem de valor Adicionado do ICMS ST Informada caso a modalidade de determinação da BC da ST seja MVA, a critério da unidade federada. Criada a Regra de Validação N18-20, não permitindo informação do percentual da margem de valor Adicionado do ICMS ST Informada caso a modalidade de determinação da BC da ST não for MVA, a critério da unidade federada. Criada a Regra de Validação W03-20, impedindo a informação de um valor de Base de Cálculo superior ao valor máximo estabelecido pela respectiva SEFAZ. Emitente: Criada a Regra de Validação 1C03-10, impedindo a informação de Razão Social do emitente diferente da existente no cadastro da SEFAZ. Destinatário: Criadas as Regras de Validação 5E17-10, 5E17-20, 5E1730, 5E17-40, 5E17-43, 5E17-46, 5E17-50, 5E17-60, 5E17-63, 5E17-70 e 5E17-80, para verificar se o destinatário está sendo informado corretamente ou se está em situação que o impeça de constar na NF-e como destinatário na operação com mercadoria ou prestação de serviços.  Serviço Autorização EPEC: Criadas as Regras de Validação 6P31-10, 6P31-20, 6P31-30, 6P31-40, 6P31-43, 6P31-46, 6P31-50, 6P31-60 e 6P31-63, para verificar se o destinatário está sendo informado corretamente ou se está em situação que o impeça de constar na NF-e como destinatário na operação com mercadoria ou prestação de serviços.
    5 pontos
  2. Dá um confere nesse endereço aqui. Tem tudo aí https://acbr.sourceforge.io/ACBrMonitor/PassoaPassoNFeNFCe.html
    3 pontos
  3. Sim, problema na SEFAZ/MG. Aumentando o timeout às vezes se consegue retorno.
    3 pontos
  4. O problema é na SEFAZ... há diversos relatos deste tipo de retorno em MG.
    3 pontos
  5. Muito obrigado. Foi pro SVN na revisão 16971. Favor atualizar, testar e reportar qualquer problema.
    3 pontos
  6. Anaê É possível sim, o ACBr comunica-se em moto TCP/IP e em modo texto. Em moto texto, extremamente simples: você escreve um texto previamente formatado, com o comando desejado e aguarda a resposta também em moto txt e então interpreta esse texto de retorno sem segredo Os tutoriais por aqui são numerosos, vastos e valiosos
    3 pontos
  7. Boa tarde, Durante o processo de homologação do boleto, a homologadora solicitou a alteração no arquivo CNAB 400. "No manual especifica que o preenchimento da posição 161 obriga o preenchimento das posições 162-173, sendo assim é preciso deixar em branco a posição 161 ou preencher com zeros as posições 162-173 que assim também não será cobrado juros." Alteração realizada deverá informar com zero as posições 162-173. Estou encaminhando o arquivo ACBrBancoBanrisul.pas com a alteração, para ser verificada a possibilidade da mesma ser enviada ao repositório. ACBrBancoBanrisul.pas
    2 pontos
  8. Boa tarde. Você chegou a ver este tópico? Att.
    2 pontos
  9. Boa tarde. Ajuste disponível no svn. Att.
    2 pontos
  10. Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.
    2 pontos
  11. Atualização ok. Obrigado
    2 pontos
  12. Felipe, obrigado pelo retorno. Consegui resolver o problema. Tentei até finalizar este tópico mas não consegui encontra-lo novamente. Obrigado.
    2 pontos
  13. acabei de receber SEFAZ MG
    2 pontos
  14. O ACBrSAT fala com a DLL do fabricante, e não com o SAT... a msg de erro retornada, vem da DLL do fabricante... então provavelmente é a DLL que não está tratando corretamente o fato do SAT não estar conectado...
    2 pontos
  15. Bom dia Adilson, Ocorreram diversas alterações nos fontes, favor atualizar os fontes e faça novos testes. Fiz um teste com o seu XML e foi mostrado: Incentivador Cultural: Não
    2 pontos
  16. Muito obrigado pela contribuição. No SVN na revisão 16970. Favor atualizar, testar e reportar qualquer problema.
    2 pontos
  17. Obrigado meu caro, descobri o problema! A inicialização do bloco k100 estava errada, obrigado!
    2 pontos
  18. Bom dia Ana ! Exatamente, são enviados 2 ou + eventos S-2200 para os vínculos existentes com a mesma empresa ( contratos de trabalho ). Vínculos anteriores a obrigação do eSocial, precisa enviar 1 de cada vez, sendo que o 1º cadastro deve ser informado como 1º envio. Tag [vinculo], cadIni e os demais com "N" Caso tenha problema no envio a partir do 2º vínculo, envie o S-2200 como "Alterlção" que também vai manter a informação do 1º vínculo ( acredito ser BUG do e-Social mas também vai resolver ) o problema. Boa sorte *S-2206 é para alterar dados cadastrais preenchidos erroneamente ( documentos, endereço, etc... ). Não serve para informar dados de Vínculo
    2 pontos
  19. @EMBarbosa, em nossa aplicação utilizamos uma mesma rotina para gerar o XML de NF-e e NFC-e, que é usado posteriormente na impressão. A impressão de NFC-e no ACBr não possui esse tratamento de adicionar o "ponto-e-vírgula" automaticamente no InfAdFisco. Para não ter que tratar para retirar ou não o "ponto-e-vírgula" dependendo do modelo de nota, optei por tratar isso na própria geração do report do DANFE. Como também essa alteração não gera nenhum impacto maior, para mim ficou mais fácil fazer de forma.
    2 pontos
  20. Bom dia. Obrigada, adicionado para análise. Att.
    2 pontos
  21. Bom dia. As tags do grupo responsável técnico devem ser enviadas em produção somente em 03/06 para as UFS que exigem...tente remover e veja se para de dar erro. Att.
    2 pontos
  22. Bom dia, Obtive duas respostas diferentes da SEFAZ, encaminhei email novamente pra mais algumas pra ver. SEFAZ SC - Apenas grupo de responsável técnico foi para 03/06/2019, campos do local de retirada/entrega e vICMSSubstituto se mantém em 07/05/2019. SEFAZ MT - Todos os campos da NT, grupo responsável técnico, campos do local de retirada/entrega e vICMSSubstituto passaram para 03/06/2019. Assim fica difícil de desenvolver as coisas, cada SEFAZ tem um entendimento diferente. Na medida que os demais retornarem posto aqui, mandei para o SEFAZ RS que abrange grande parte do Brasil, aguardar pra ver.
    2 pontos
  23. Na tarde de hoje alguns clientes conseguiram enviar eventos. Problema realmente é com o site do eSocial, melhor solução era o empresariado se fazer presente e suspender a colaboração com essa jabuticaba. ? Agradecimentos a todos os colaboradores
    2 pontos
  24. Olá Pessoal, Muitos tem interesse em obter o XML do fornecedor para facilitar a entrada dos materiais no Estoque, Contas a Pagar, etc. Segundo a legislação, quem emite uma NF-e tem por obrigação legal de disponibilizar o XML assinado e com o protocolo de autorização ao destinatário da mercadoria, assim que a SEFAZ autorizar a nota. Essa disponibilização pode ser feita por e-mail, ou seja, o emitente envia para o destinatário o XML via e-mail. Sabemos que isso nem sempre ocorre, por 2 motivos: 1. No cadastro do destinatário não consta o endereço de e-mail; 2. A aplicação do emitente não possui esse recurso ou esta desativado. Mas temos uma alternativa. Com certeza o DANFE foi impresso e entregue junto com a mercadoria. De posse do DANFE temos a chave e com ela podemos primeiramente enviar o evento de Manifestação do Destinatário. Temos duas situações: 1. Se as mercadorias foram entregues conforme o combinado, devemos enviar o evento: Confirmação da Operação (Código: 210200); 2. Se algo estiver errado e alguma mercadoria esta errada, quebrada, ...., devemos enviar o evento: Operação não Realizada (Código: 210240), neste evento se faz necessário informar uma justificativa. Após manifestar todas as notas, podemos obter o XML através do método: DistribuicaoDFePorChaveNFe, esse método possui 3 parâmetros, sendo eles: Código da UF do Destinatário, CNPJ do Destinatário e a Chave da NF-e previamente manifestada. Conclui-se que devemos executar o método acima para cada nota manifestada. Informação importante, tanto a Manifestação do Destinatário quanto o Distribuição DF-e, são atendidos pelo Ambiente Nacional, portanto não tem nada haver com a SEFAZ-Autorizadora do emitente da nota ou do destinatário da mercadoria. Se algo falhar nesse processo, a "culpa" é do Ambiente Nacional.
    1 ponto
  25. Jesus rsrs não sei que trocou na configuração do componente e tirou de Órgão Publico e colocou pessoa jurídica! To a mais ou menos umas 6 horas procurando no código que eu tava errando pois lá no componente eu tinha já tinha configurado! Mais obrigado @Emerson Moreno!
    1 ponto
  26. Onde marquei de vermelho, é onde informo o tipo de empregador, no meu caso, órgão publico, creio que no seu tb deva ser, porém, você precisa especificar isso: TEmpregador = (tePessoaJuridica, teOrgaoPublico, tePessoaFisica, teOrgaoPublicoExecutivoFederal, teOrgaoPublicoLegislativoFederal, teOrgaoPublicoJudiciarioFederal, teOrgaoPublicoAutonomoFederal); Observe que eu coloco o índice 1 que é teOrgaoPublico.
    1 ponto
  27. Boa tarde, elvis.muniz. Veja a discussão do mesmo assunto abaixo:
    1 ponto
  28. Boa tarde. Veja neste tópico que a SEFAZ-MG está trabalhando na solução, conforme post do colega @Leonardo de Alice Att.
    1 ponto
  29. Atualização ok. Obrigado
    1 ponto
  30. Bom dia. Este banco tem somente o campo SeuNumero, por este motivo não estava adiantando passar a propriedade NumeroDocumento. Att.
    1 ponto
  31. Verifique se você instalou corretamente o SiTEF Emulador... na dúvida, apague tudo e siga atentamente as instruções de instalação
    1 ponto
  32. Bom dia. Creio que se você se refira ao retorno da cobrança, pelo que me recordo dos manuais, não existe diferença se a quitação foi por pagamento executado pelo cliente ou se foi de forma automática. Att.
    1 ponto
  33. No momento, o componente de importação é mantido mais pela comunidade do que pelos desenvolvedores do ACBr. Se você conseguir corrigir o erro e quiser enviar uma sugestão de correção, ficamos gratos e vamos analisar. Do contrário, teremos que aguardar alguém que possa fazer isso.
    1 ponto
  34. já achei não li a observações Informar somente se for diferente mesmo!
    1 ponto
  35. Submeta o XML a um programa que faça a validação de Schema... você pode por exemplo, usar o InteliSAT da Tanca http://www.tanca.com.br/drivers.php?cat=24&sub=43
    1 ponto
  36. Bom dia, Muito obrigado pela colaboração, enviei para o repositório com uma pequena alteração. Favor atualizar os fontes e refaça os testes.
    1 ponto
  37. Bom dia Almir, Até onde sei a cidade de Jaguariúna contratou o provedor Giss. O componente já tem esse provedor implementado, sugiro que utilize o programa exemplo do componente ACBrNFSe para realizar os testes.
    1 ponto
  38. Bom dia acg.net, Muito obrigado pela colaboração, já se encontra no repositório.
    1 ponto
  39. Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.
    1 ponto
  40. Tópico fechado por falta de retorno do usuário
    1 ponto
  41. Bom dia Michele, Fiz uma alteração na unit responsável por gerar o XML, acredito que vá resolver o problema, ainda hoje estarei enviando para o repositório.
    1 ponto
  42. Obrigado EMBARBOSA por me ajudar!! Então desculpa a dúvida mal formulada, e que como tava tentando resolver isso e tudo que tento não dá certo e com o cliente buzinando na orelha acabei formulando mal a dúvida. Não vai mais acontecer. Mas você entendeu corretamente era essa minha dúvida como voltar ao valor anterior do defaultfilter. Fiz do jeito que você fez até comemorei ao ver a sua solução mas ele pega o valor anterior que nil ae depois de imprimir retorno o valor mas também não funcionou, acho que algum bug do próprio fortes. Tentei também o RLRcobapea.defaultfilter.destroy mas da erro acces violation. Tentei também atribuir dessa forma: RLRcobapea.defaultfilter:=''; //não compila RLRcobapea.defaultfilter:=null; //também não compila E acho que é algum bug mesmo no fortes nessa parte do default filter Vou continuar buscando uma solução se encontrar posto aqui. Muito Obrigado EMBARBOSA! E mais uma vez desculpa pela questão mal formulada.
    1 ponto
  43. Também daria certo. Mas não resolveria a seguinte situação: As clinicas de medicina do trabalho geram os arquivos de saude e segurança do trabalhador (1060,2220....). Ela gera os eventos e não necessariamente precisa assiná-los, pois ela apenas gera o XML e envia para a empresa do funcionário, que se encarrega de recepcionar este arquivo, assinar e enviar ao eSocial.
    1 ponto
  44. Show!!, vi nos fontes do acbr essa mesma validação aqui , e estou fazendo agora.obrigado!!
    1 ponto
  45. Opa, bom dia... Apenas uma adendo: O prazo para a implementação foi alterado na revisão 1.30 da Nota Técnica 2018.005. E os estados que passarão a obrigar o grupo de responsável técnico a partir da data 03/06/2019, são: Amazonas Mato Grosso do Sul Pernambuco Paraná Santa Catarina Tocantins **Observe que o Estado de Alagoas não está mais na lista. Para os demais estados o correto é ligar na SEFAZ e perguntar se eles irão obrigar o preenchimento desse grupo e se sim, qual será a data.
    1 ponto
  46. Bom dia amigo, Isso foi enviado por e-mail pelo auditor fiscal, inclusive aos órgãos homologadores. No Ato DIAT Nro 30/2018, diz o seguinte: Fonte: http://legislacao.sef.sc.gov.br/html/Atos_Diat/2018/AtoDiat_18_030.htm Obrigado,
    1 ponto
  47. Oi pessoal! Como tive vários problemas com formatação do XML para o SAT, achei um link no SAT da Bematch que valida o conteúdo do XML antes do envio para o SAT. Isso resolveu todos os meus problemas, espero que possa ajudar vocês também! Segue: http://bematechpartners.com.br/portalPartners/index.php/suporte-validador-xml-sat/ Abs
    1 ponto
  48. Obrigado pelas dicas, vlw, vou fazer isso em meus clientes.
    1 ponto
  49. Boa tarde. Por favor anexe a unit alterada. Att.
    1 ponto
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...