Painel de líderes

PERGUNTA: Eu uso o ACBr. Posso colocar o ACBr como Reponsável Técnico na emissão de algum documento fiscal eletrônico (ou DF-e, isto é, NF-e, NFC-e, CT-e, MDF-e, etc...) ? Mesmo que você use o ACBrMonitor Plus, a ACBrLib, os componente ACBr, algum programa exemplo que disponibilizamos, a resposta simples é NÃO. Não entenda mal. Reafirmamos nosso compromisso em ajudar os usuários do ACBr a resolver seus problemas no uso dos componentes, bibliotecas ou aplicativos que disponibilizamos na medida do possível. E claro, damos prioridades aos casos reportados por usuários que fazem uso do SAC ACBr. Mas não somos o responsável técnico pelo seu sistema, mesmo que ele use qualquer ferramenta que provemos. Talvez você queira entender um pouco mais, então vamos a uma resposta longa sobre isso. Vamos usar como exemplo a NF-e e NFC-e que são de longe os DF-es mais utilizados. Se você ler a nota técnica 2018.005 da NF-e/NFC-e vai encontrar o item "2 Sobre a Identificação do Responsável Técnico". Nesse item há a seguinte frase no parágrafo que explica o que é essa informação (grifo é meu): Veja que a primeira frase menciona que o "responsável técnico" pode não ser simplesmente um desenvolvedor, mas a empresa responsável tecnicamente pelo sistema de emissão. O que neste caso é vocês. Vocês respondem perante seu cliente e perante as autoridades pela emissão do documento fiscal. Os produtos do projeto ACBr (seja algum componente, o ACBrMonitor, ou uma ACBrLib) nesse processo é apenas uma ferramenta parte do seu software e não o sistema em si. Ou seja, é um framework/biblioteca/componente que ajuda seu sistema e sua empresa a emitir os documentos. Veja, não disponibilizamos sistemas para emissão, apenas ferramentas para ajudar na emissão. Isso fica mais claro quando lemos o restante do parágrafo, porque ele explica não só o que é o "responsável técnico", mas também o objetivo dessa informação ser necessária. Veja: A ideia é a SEFAZ poder entrar em contato com o responsável pelo emissor em caso de dúvidas ou problemas na emissão. Em caso de anomalias na emissão, com quem a SEFAZ teria que entrar em contato? Por exemplo: Em uma das reuniões do ENCAT, foi relatado que um sistema tentou retransmitir uma nota com erros no XML, por 70.000 vezes! Ou seja, mesmo recebendo o erro de rejeição por XML inválido, a aplicação ficou em algum Loop, tentando retransmitir o XML que já deveria saber que seria rejeitado. Isso é na verdade um ataque de DDOS, nos servidores do SEFAZ. Talvez um ataque sem intenção, mas não deixa de ser um... Mas nesse caso, quem a SEFAZ teria que contatar se essa empresa fosse seu cliente? É evidente que em caso de dúvidas ou problemas sobre o uso nas empresas que são seus clientes eles deverão entrar em contato com a sua empresa. Afinal de contas, nós do ACBr não sabemos como seu sistema funciona, muito menos conhecemos os seus clientes. Ainda mais, qualquer solução do ACBr, (quero dizer ACBrMonitor, ACBrLib, ou qualquer componente ou biblioteca que fornecemos), por si só nunca faz uso de um WebService. Qualquer WebService é acionado por sua aplicação. Ela, a sua aplicação, é responsável pela emissão. Chamar o ACBr de responsável seria basicamente o mesmo que colocar como responsável a Microsoft porque você usa o Windows nos seus clientes, ou a biblioteca OpenSSL porque você a usa pra assinar os documentos. Existe mais um detalhe que o item "2.1 Código de Segurança do Responsável Técnico - CSRT" nos ajuda a entender. Esse item fala do credenciamento do software emissor de DF-e na SEFAZ da UF e da empresa responsável. Se sua UF já tem esse cadastro, ou algum cadastro similar como era o caso do PAF-ECF, sem dúvida você entende que é sua empresa e seu software que deve ser cadastrado, independente de usar ou não alguma ferramenta de terceiros em seu sistema. Peraí! Tem mais! No terceiro parágrafo há a seguinte explicação sobre o CSRT, que pode ser exigido em formato de hash: Mais uma vez, se essa é uma informação conhecida somente entre a empresa desenvolvedora e Fisco, não teria como ser disponibilizada por nós. Senão, poderíamos nos passar por você. Seria como você dar seu RG ou Passaporte para outra pessoa se passar por você. Então para pra deixar isso claro pra qualquer pessoa com dúvida no futuro: O projeto ACBr não se responsabiliza por mal uso de nenhum dos programas, bibliotecas, componentes, ou códigos fontes disponibilizados. Usar qualquer um desses, incluindo o ACBrMonitor Plus, não dá direito a ninguém colocar o Projeto ACBr como responsável técnico, ou de qualquer outra forma responsável perante clientes ou autoridades. Se alguém pensar diferente, informamos que não tem licença para utilizar o que provemos. Pedimos o favor de ler com cuidado as licenças LGPL e GPL que usamos.

MG gera somente o CSCid 000001 com o mesmo CSC para homologação e produção. Este erro mencionado ocorreu nos contribuintes que fizeram o cadastro através do Fale Conosco na mesma semana que liberaram o acesso ao Siare. Não sei informar o motivo, mas estes contribuintes não conseguem gerar nada em homologação. O que pode tentar (em 1 cliente meu funcionou) é entrar no Siare e gerar novamente o CSC. Como se fosse iniciar o processo. Primeiro gera em homologação e após 2 horas gera produção. Note que o CSC será o mesmo anterior, nada muda, acho que somente grava no servidor de homologação da Sefaz. Charles

Boa tarde! Certifique-se que está com o ACBr atualizado e siga as instruções do tópico abaixo.

Acabei de passar por esse problema, o instalador não preencheu o path library para 64 bits, tive que adicionar manualmente. Tools -> Options -> Language -> Delphi Options -> Library -> Selected Platform -> Windows 64-bit

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.

Olá pessoal, Com a NT 2018.005 foi introduzida uma nova rejeição para NFe: 938 - Rejeição: Não informada vBCSTRet, pST, vICMSSubstituto e vICMSSTRet. Os detalhes dessa rejeição foram alterados nas várias versões da NT, mas infelizmente isso já está causando algum problema (como podem ver nesse tópico aqui). Como é uma rejeição facultativa e cada UF tem uma legislação, tivemos que adicionar uma nova propriedade no componente ACBrNFe para lidar com a situação. A nova propriedade se chama ForcarGerarTagRejeicao938. Após atualizar os componentes, não esqueça de reinstalar. Vamos a uma explicação mais longa... O problema Como a descrição da rejeição explica, algumas UFs podem exigir a informação de algumas tags, como vICMSSubsituto, isso mesmo quando o valor da tag for zero. Por padrão o ACBrNFe não gera tags facultativas que são informadas com valor zero. E esse é o caso da tag vICMSSubstituto. Mas como essa é uma tag facultativa, não devia ser obrigatório para algumas UFs informá-la. E por isso, não podemos obrigar o ACBrNFe informar sempre. Assim a ideia é termos uma configuração que você possa alterar. Poderemos com essa propriedade forçar gerar a tag de acordo com a necessidade de seu cliente ou da UF dele. A solução A propriedade (ou configuração) criada ForcarGerarTagRejeicao938 foi adicionada no ACBrNFe de modo que pode ser acessada como no código abaixo: ACBrNFe1.Configuracoes.Geral.ForcarGerarTagRejeicao938:= fgtNunca; Ou talvez no Object Inspector como abaixo: Importante: Embora a propriedade esteja disponível para ser alterada no Object Inspector, você provavelmente vai querer parametrizar isso no seu aplicativo. Afinal, talvez você precise alterar essa propriedade de um cliente para outro, ou de uma data para outra. As opções são: fgtNunca -> Se o valor for zero, não vai forçar a geração da tag nunca; fgtSomenteProducao -> Força a tag ser gerada no ambiente de produção mesmo que o valor seja zero; fgtSomenteHomologacao -> Força a tag ser gerada no ambiente de homologação mesmo que o valor seja zero; fgtSempre -> mesmo que o valor seja zero, a tag será gerada sempre; A configuração padrão é fgtNunca conforme o comportamento do componente antes dessas alterações. Qual opção eu devo escolher? Como explicado, essa configuração foi necessária por causa de problemas em certas UFs. Então para escolher a melhor opção você precisa saber o que está sendo exigido no Webservice que você está acessando. Por exemplo, se você não está recebendo a rejeição, não há necessidade de alterar a configuração. Mas se está recebendo somente em homologação, quer dizer, a tag está sendo exigida somente em homologação, use a opção fgtSomenteHomologacao. E assim por diante.

Fantástico! Muito obrigado!

Ítalo, muito obrigado. Funcionou corretamente. Segue anexo a unit pcesS2299.pas corrigida. pcesS2299.pas

Muito Obrigado... já no SVN... rev: 16983

Obrigado deu certo. Troquei o provedor e a conexão de internet e funcionou.

Para conhecer mais o ACBrMonitor sugiro também o Video abaixo, acompanha o modelo do arquivo para NFe e o link do Manual:

E ae galera do "mau/mal" hehe... Liguei as 07h da manhã pra Receita do PR e informaram que os Schemas seriam atualizados nos servidores da SEFAZ somente depois das 10h e que todas as notas em contingência com a tag infresptecnico seriam aceitas, disseram que sempre fizeram isso, nunca fazem nada na virada do dia. Já passamos das 10h e o problema persiste, liguei lá novamente e informaram as 12h agora. Não reatualizei nenhum cliente meu, todos estão emitindo em contingência. Com relação ao ST não tenho nenhum relato ainda pra mencionar, só do infresptec.

Bom dia. Veja as orientações deste tópico para solucionar seu problema. https://www.projetoacbr.com.br/forum/topic/50787-nt-2018005-nfe-938-rejeição-não-informada-vbcstret-pst-vicmssubstituto-e-vicmsstret/ Att.

Bom dia. Verifique a parametrização criada recentemente no componente conforme o tópico a seguir, infelizmente estas tags ficaram uma confusão..recomendo testar e ver a forma que é aceito pela UF. A prorrogação foi somente para o grupo Responsável Técnico. Att.

Pessoal, consegui resolver, vou postar aqui o que era caso aconteça com alguém. Eu havia feito uma alteração no fonte do arquivo ACBrNFeDANFEFRDM.pas, e por esse motivo mesmo um SVN Update no Tortoise o ACBr não podei ser instalado pois o arquivo estava alterado, o que fiz para resolver foi ir na pasta do ACBr e dar um Revert no Tortoise e depois fazer o Update, como isso foi tudo normal.

Olá pessoal, A solução para este processo acabou sendo em outra plataforma e linguagem, devido a política de assinatura para API Serpro seguir o padrão CAdES. Já estou com o assinador implementado. Conhecer o projeto ACBR irá me auxiliar em futuros projetos aqui na empresa. Obrigado pela contribuição de todos. Por favor, pode encerrar o tópico.

Boa tarde. Os layouts estão na página da SEFAZ. Att.

Seguindo a dica Francisco Vieira modifiquei meu código para utilizar xsMsXML conforme abaixo e tudo voltou a funcionar corretamente. SSLXmlSignLib := xsMsXml; Francisco e Dercide, obrigado pela ajuda.

Obtive a resposta da receita sobre o cancelamento por substituição. A equipe da STI informou que esse evento ainda não está implementado em nosso sistema. Está previsto para ser implementado até dia 15 de maio.

Obrigado @Italo Jurisato Junior... ficou um ótimo resumo

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

As alterações funcionaram corretamente. Favor fechar o tópico. Obrigado à equipe ACBr.

Obrigado Ítalo!

Boa tarde Claudio, Você pode acrescentar a cidade em questão da mesma forma que as demais que utilizam o mesmo provedor.

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

Vou utilizar o componente para visualização com o Fortes Report, pois com ele gera certinho a visualização. Obrigado

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

É no SIARE. Veja o link abaixo: http://www.sped.fazenda.mg.gov.br/spedmg/export/sites/spedmg/nfce/downloads/Internet_Passo-a-passo-manual-de-cadastro-NFC-e.pdf

ainda não, vou tentar o link! muito obrigado!!!

Boa tarde, Muito obrigado pela ajuda. Isso que vc disse faz todo o sentido. Mas no SIARE nao estou conseguindo consultar o CSC/TOKEN Voce sabe me dizer aonde eu vejo estes dados de homologacao ?

Estamos em um consenso, @Larry. Agora, esperamos que seja isto mesmo. Estamos tratando logo no processo de entrada de notas no sistema, quando trata-se de CST 010, 030, 070, por exemplo, já realizamos a divisão pela quantidade e armazenamos sempre o valor unitário da última entrada por produto. Assim, quando demos saída com CST 060 ou CSOSN 500, já temos os valores bonitinhos armazenados, daí é só puxar e multiplicar pela quantidade. É isso. Até mais.

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

continuando... Nestas duas chaves a diferença é o tag TpEmiss (e o digito verificador) Então qual nota é válida, a que processou na SEFAZ (chave1) ou a que o cliente levou impressa (chave2) ? Solução 1 : No retorno de duplicidade temos o seguinte retorno : Seria possível quebrar o retorno pegar a chave que retornou e executar uma consulta na tentativa de recuperar o XML, Problema : a nota em contingência que o cliente levou, a qual tem uma chave e ao consultar nunca será válida. Ao meu ver isso seria fraude passível de penalizações LOGO SOLUÇÃO 1 é INVÁLIDA. Solução 2 : Com o retorno acima, pegar a chave da duplicidade e executar o evento de Cancelamento Por Substituição, aqui temos uma explicação do que é. Eu ainda não implementei este evento, estou ainda fazendo análise do caso. Mas aí me deparei com as rejeição para o referido evento : O que me preocupa é a Rejeição 912 pois a contingência não foi transmitida, logo não vai existir Problema : ainda estou montando ambiente para verificar o caso, assim que tiver resultado posto aqui.

3.1 - Não faça flooding - Inundar o fórum com posts repetidos, com a mesma dúvida ou as mesmas palavras é chamado de flooding. Isso é proibido. Apenas um post feito no lugar certo é suficiente. Pesquise antes de postar, talvez sua dúvida já está respondida em outro post. Favor leia as regras do fórum. Tópico relacionado no link abaixo:

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

Foi isso mesmo que fiz. explicação para Win64 não é necessário instalar mas sim compilar, pois quando instala para win32 ele já deixa registrado para win64.

exatamente com esse é possível conectar. mas no tópico anterior tu já quer do firebird. mas isso é somente para o mysql que eles usam embutido será que vai lhe ajduar?

Boa Noite Posta os fontes aqui no forum mesmo

Acho que já sei, o tamanho é 15-256.

Boa tarde. Você procurou na estrutura a seguir? ...\trunk2\Exemplos\ACBrDFe\ACBreSocial Att.

Posso sim, obrigado pela atenção Daniel. Pode fechar o Tópico

No seu caso, terá que realizar os testes com a inscrição e certificado digital de um cliente de MG. Aqui em MG, a IE de MG é pré-requisito.

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

Bom dia, Carlos Paiva Veja o link abaixo: http://portal.esocial.gov.br/institucional/documentacao-tecnica

Bom dia, Ariston Santos. Tente ajustar os valores da largura. Verifique o zoom do vídeo de seu windows.

Boa tarde, Conforme pôde ser observado por um grande número de membros da comunidade, desde os últimos dias de abril vinha ocorrendo na maioria das UFs a rejeição Endereço do site da UF de Consulta por chave de acesso diverge do previsto ao tentar enviar a NFCe em ambiente de homologação. Motivo da Rejeição Conforme foi divulgado posteriormente pela SEFAZ, de forma não oficial, ou seja, sem a publicação de NTs ou outras informações nos portais relativos a NFCe, esta rejeição passou a ocorrer devido a implementação da regra ZX03-20 existente na NT 2016.002 versão 1.61, a qual determina a validação da URL de Consulta por Chave de Acesso conforme tabela disponibilizada no portal do ENCAT. Estas validações entraram em vigor em ambiente de homologação no dia 22/04/2019 e em produção entrarão em 20/05/2019. Solução Os fontes do ACBr e por consequência o ACBrMonitorPlus SAC, foram atualizados com as URLs corretas conforme documentação disponível na página do ENCAT. Porém, em alguns casos, os endereços indicados pelo ENCAT ainda sim estavam incorretos. Com base no feedback de diversos usuários de nossa comunidade, novos ajustes foram enviados para o SVN do ACBr, no arquivo ACBrNFeServicos.ini Dicas para Minimizar o Impacto em seus clientes Se você utiliza o componente ACBrNFe para emissão da NFCe, procure sempre disponibilizar na mesma pasta do seu binário (executável) o arquivo ACBrNFeServicos.ini. Desta forma, o componente ACBrNFe, irá fazer uso do arquivo ACBrNFeServicos.ini existente no diretório, ao invés de usar as URLs internas, que são compiladas como "Resource", e anexadas ao componente... Isso é extremamente vantajoso, pois lhe confere grande agilidade na resolução de problemas de URLs... Caso sejam detectadas novas alterações de URLs, basta realizar a substituição do arquivo ACBrNFeServicos.ini, evitando portanto a necessidade de atualizar toda a aplicação. Eu não distribuo o ACBrNFeServicos.ini em meus instaladores? Preciso recompilar e atualizar meus clientes para que as novas URLs entrem em vigor ? Se você não quer ou não pode distribuir o ACBrNFeServicos.ini, na mesma pasta da sua aplicação, então não há outra maneira a não ser disponibilizar um novo binário para o seu cliente... Porém antes , faça um teste, é simples e rápido... Apenas copie o arquivo ACBrNFeServicos.ini no mesmo diretório de sua aplicação, e observe que as novas URLs serão utilizadas, pois o componente ACBrNFe irá priorizar o arquivo em disco. Ainda tem Dúvidas? Acesse os sub-fóruns sobre NFCe e crie um novo tópico relatando seu questionamento. Lembre-se que se for usuário do SAC Anual você também pode falar conosco pelo chat ACBr.

Boa tarde a todos, Conforme consta na Nota Técnica 2018/005 versão 1.30 (disponível na Biblioteca ACBr) as alterações referentes aos grupos de Retirada e Entrega que entrará em vigor no ambiente de produção agora dia 07/05/2019. Alterações no grupo Retirada As alterações se referem aos campos que estão destacados em amarelo, notem que todos eles são opcionais, isso significa que se eles não forem gerados não vai ocorrer nenhum problema, ou seja, a nota vai ser autorizada pela SEFAZ. Como é de costume no componente ACBrNFe esses novos campos estão com a mesma grafia apresentada na Nota Técnica. Observação importante, não devemos gerar o XML com esses novos campos e enviar para o ambiente de produção, pois este só estará apto a partir do dia 07/05/2019, mas nada impede de gerar e enviar para o ambiente de homologação, pois esse já esta aceitando o XML com os novos campos. Alterações no grupo Entrega Idem ao grupo de Retirada. Fragmento do XML com todos os campos de entrega informados: Para quem utiliza o ACBrMonitorPlus, abaixo as alterações em negrito na seções [Retirada] e [Entrega]: [Retirada] CNPJCPF= xNome= xLgr= nro= xCpl= xBairro= cMun= xMun= UF= CEP= PaisCod= Pais= Fone= Email= IE= [Entrega] CNPJCPF= xNome= xLgr= nro= xCpl= xBairro= cMun= xMun= UF= CEP= PaisCod= Pais= Fone= Email= IE= O ACBrMonitorPLUS SAC já esta preparado para gerar o XML com os novos campos, mas vale reforçar mais uma vez que a SEFAZ só vai aceitar esse novos campos no ambiente de produção a partir do dia 07/05/2019. Você pode baixar a versão atualizada do ACBrMonitorPLUS SAC em:

Em anexo algumas alterações para utilização dos novos WebServices: http://webservices.sathomologa.sef.sc.gov.br/wsDfeSiv/BlocoX.asmx Luciano. ACBrBlocoX.zip

Muito Obrigado... tópico movido para a área de Notícias

Pessoal, Boa tarde... Banco Itau acabou de entrar em contato, alegaram que a rejeição foi devido não ter informado a DATA DA MULTA conforme pagina 38 do Manual (Cobrança CNAB400), *(Sta mae de Deus)... se já existe a informação (vencimento) para que uma segunda data para informar a partir de quando cobrar multa???? ; E tem mais, temos outros clientes que utilizam o mesmo sistema e carteira de cobrança e seus arquivos estão sendo processados normalmente (mesmo sem a data da multa); Vai saber.... Abraços a todos,