Painel de líderes
Conteúdo popular
Showing content with the highest reputation on 30-04-2019 em Posts
-
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
-
Dá um confere nesse endereço aqui. Tem tudo aí https://acbr.sourceforge.io/ACBrMonitor/PassoaPassoNFeNFCe.html3 pontos
-
Sim, problema na SEFAZ/MG. Aumentando o timeout às vezes se consegue retorno.3 pontos
-
O problema é na SEFAZ... há diversos relatos deste tipo de retorno em MG.3 pontos
-
Muito obrigado. Foi pro SVN na revisão 16971. Favor atualizar, testar e reportar qualquer problema.3 pontos
-
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 valiosos3 pontos
-
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.pas2 pontos
-
2 pontos
-
2 pontos
-
2 pontos
-
2 pontos
-
Felipe, obrigado pelo retorno. Consegui resolver o problema. Tentei até finalizar este tópico mas não consegui encontra-lo novamente. Obrigado.2 pontos
-
2 pontos
-
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
-
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ão2 pontos
-
Muito obrigado pela contribuição. No SVN na revisão 16970. Favor atualizar, testar e reportar qualquer problema.2 pontos
-
Obrigado meu caro, descobri o problema! A inicialização do bloco k100 estava errada, obrigado!2 pontos
-
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ínculo2 pontos
-
@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
-
2 pontos
-
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
-
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
-
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
-
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
-
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
-
1 ponto
-
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
-
1 ponto
-
Bom dia. Este banco tem somente o campo SeuNumero, por este motivo não estava adiantando passar a propriedade NumeroDocumento. Att.1 ponto
-
Verifique se você instalou corretamente o SiTEF Emulador... na dúvida, apague tudo e siga atentamente as instruções de instalação1 ponto
-
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
-
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
-
já achei não li a observações Informar somente se for diferente mesmo!1 ponto
-
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=431 ponto
-
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
-
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
-
Bom dia acg.net, Muito obrigado pela colaboração, já se encontra no repositório.1 ponto
-
Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.1 ponto
-
1 ponto
-
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
-
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
-
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
-
Show!!, vi nos fontes do acbr essa mesma validação aqui , e estou fazendo agora.obrigado!!1 ponto
-
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
-
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
-
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/ Abs1 ponto
-
1 ponto
-
1 ponto
