Painel de líderes

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.

Boa tarde, tiagopassarella. Veja que é um problema na Sefaz:

Dá um confere nesse endereço aqui. Tem tudo aí https://acbr.sourceforge.io/ACBrMonitor/PassoaPassoNFeNFCe.html

Sim, problema na SEFAZ/MG. Aumentando o timeout às vezes se consegue retorno.

O problema é na SEFAZ... há diversos relatos deste tipo de retorno em MG.

Muito obrigado. Foi pro SVN na revisão 16971. Favor atualizar, testar e reportar qualquer problema.

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

Eu repeti os passos aqui utilizando o Lazarus 2.0.2 e não consegui reproduzir o problema. Então, dei uma olhada no CallStack reportado na sua imagem e não consegui visualizar nada no código listado que poderia gerar esse vazamento de memória. Talvez seja algo específico de uma versão ou do Lazarus ou do LazReport...

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

Boa tarde. Você chegou a ver este tópico? Att.

Este realmente não existe mais, pode ser que esteja desatualizado no manual... Pode utilizar o metodo para ambiente https://acbr.sourceforge.io/ACBrMonitor/NFESetAmbiente.html , mas a UF deve ser configurada na aplicação mesmo

Boa tarde. Ajuste disponível no svn. Att.

Consegui realizar o Download do XML da NF-e pelo WebBrowser, foi somente setar a Propriedade do TWebBrowser.Silent = False; A partir dai a opção para selecionar o certificado ja aparece, e é só salvar para arquivo.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Atualização ok. Obrigado

Felipe, obrigado pelo retorno. Consegui resolver o problema. Tentei até finalizar este tópico mas não consegui encontra-lo novamente. Obrigado.

acabei de receber SEFAZ MG

Parece que você está desconectando antes de ler a resposta... Teste a conexão com esse exemplo (muito simples), em Lazarus... Os fontes estão disponíveis para download em nosso SVN ConectaACBrMonitorPLUS.zip

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...

Bom dia. O grupo responsável técnico deve ser enviado em produção somente em 03/06 e somente para as UFs que exigem tal informação..verifique se removendo este grupo, o problema cessa. Att.

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

Muito obrigado pela contribuição. No SVN na revisão 16970. Favor atualizar, testar e reportar qualquer problema.

Obrigado meu caro, descobri o problema! A inicialização do bloco k100 estava errada, obrigado!

Na tela acima deve ser configurado onde será gravado o XML Envio e autorização. Os demais XMLs configure em outra pasta conforme config. abaixo: (Salvar Arquivos Enviados/Recebidos para WebService)

Narlem, Sim, o problema é na SEFAZ, visto que outros estão com o mesmo problema.

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

@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.

Bom dia. Obrigada, adicionado para análise. Att.

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.

Bom dia Duarte, Essa nota foi emitida pelo seu fornecedor correto? Se sim, ao executar o método DistribuicaoDFePorChaveNFe o ambiente é o mesmo, pois se a nota foi enviada para o ambiente de produção e você esta fazendo teste no ambiente de homologação a mensagem que SEFAZ retorna é exatamente essa.

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.

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

No vídeo do André, tem uma imagem da tela que mostra uma configuração de quanto tempo vai esperar para fazer o teste novamente como a Juliana mencionou acima. Você pode adicionar outras coisas de acordo com a regra de negócios de sua empresa. Por exemplo uma quantidade de notas emitidas mínima antes de tentar novamente, um botão para forçar a tentativa de voltar ao normal, etc...

Olá amigo... Já havia lido esse tópico e fiquei com receio pelo fato de um usuário ter conseguido e o outro ter tido problemas. Mas eu acabo de efetuar o teste no cliente e funcionou PERFEITAMENTE com o protocolo balMagna. Abraços

Os arquivos de Log (1-*xml) são usados apenas para Debug e não precisam ser gerados... Desmarque a opção "Salvar arquivos enviados/recebidos.." Na tela indicada no Post anterior

Obrigado pela atenção pessoal, consegui resolver o problema aqui. Bom feriado a todos !!!

Boa tarde. Creio que não seja o caso do ACBrBoleto, mas para facilitar, anexe o manual. Att.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde, Configurado o registro L100 do ECF para preencher os campos VAL_CTA_REF_DEB e VAL_CTA_REF_CRED no leiaute 5. Segue: ACBR.rar

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Pode ocorrer esse erro se a pasta de schemas estiver em uma pasta compartilhada na rede e configurada no formato \\servidor\compartilhamento, e usando SSLXmlSignLib = xsLibXML2. Se for esse o caso, você pode tentar: - Mapear a pasta compartilhada para uma letra de unidade local - Copiar os schemas da rede para uma pasta local - Usar SSLXmlSignLib = xsMsXML (não recomendado para A3).

Ah sim, Muito Obrigado Italo. Pelo jeito essa delay é normal entao.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Esse artigo é antigo.. mas pode lhe dar um norte... https://www.vivaolinux.com.br/artigo/Sistema-PDV-com-PHPGTK2-e-ACBrMonitor-(parte-2)/

Bom dia, macogerais. São poucas informações para que possamos te ajudar, porém a mensagem é clara. Sugiro que verifique o arquivo validado juntamente com o manual, pois a mensagem informa que existem registros K200 sem o pai K100.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Tente com o arquivo anexo. ACBrNFeServicos.ini

Fizemos o teste e com a versão 1.2.0.53 do acbrmonitorplus agora há um novo parâmetro para o comando, com isso ficou resolvido ok: EMAIL.AdicionaAnexo(cArquivo, cNome, aAttach) Parâmetros: cArquivo – Caminho completo do arquivo que será anexado. cNome – Nome de referência do arquivo. cAttach – Define a forma de anexo no e-mail (0 - Attachement / 1 - inLine) por default envia como "0" Definição cAttach 0 - Attachement: O arquivo e enviado como anexo 1 - inLine: O arquivo e enviado no corpo do e-mail (pode ser utilizado para arquivo HTML por exemplo) Exemplo: EMAIL.AdicionaAnexo(“C:\documentos\memorando.doc”, “DocMemorando”,0)

Prezados boa tarde. Em resposta a dúvida postada pelo usuário Sommus, gostaríamos de agradecer o apontamento e dizer que realmente identificamos uma correção a ser feita no software básico do equipamento, que possui uma condição especifica de arredondamento do próprio Linux embarcado ao SAT. Gostaríamos também de frisar que o erro somente será replicado em condição isolada, sendo assim não seria motivo de gravidade na operação diária, reforçamos que esta mesma rotina esta implementada desde 2015 e o primeiro reporte foi da Sommus. A previsão de uma nova versão de software básico é de até 30 dias a partir desta data, informaremos a disponibilidade da nova versão via canais oficiais da Tanca e também pode ser acompanhada através da Sefaz em https://portal.fazenda.sp.gov.br/servicos/sat/Paginas/Modelos-SAT.aspx