Painel de líderes

Terça, 07/05/2019 Se você está atento as notícias que enviamos periodicamente em nossos Boletins e publicamos aqui nessa área de Notícias do Fórum, já deve ter se preparado e atualizado seus sistemas... mas se ainda não o fez, por favor leia esse artigo, para evitar a parada da emissão de NFe/NFCe em seus clientes finais. Nas versões 1.00 a 1.10 da NT 2018.005, ficou estabelecido que no dia 07/05/2019 entrarão em vigor a exigência de novas validações relativas a NFe/NFCe. (Você pode achar todas as NTs na Biblioteca de nosso SVN) Porém, essas novas regras foram publicas com alguns complicadores, que podem ocasionar a paralisação da emissão de NFe/NFCe. Algumas Tags, somente podem ser enviadas em Produção, a partir do 07/05/19, porém são obrigatórias a partir dessa data. Hora, isso complica tudo.... Ou seja, se enviarmos a Tag em Produção antes de 07/05, o documento será rejeitado, mas se deixarmos de enviar a Tag após 07/05, o documento igualmente será rejeitado... Então, em outras palavras, o ENCAT espera que você aplique uma parametrização ou faça rollout, em TODOS os seus clientes finais, de um dia para outro!!! Afinal, não é uma boa prática de programação, inserir uma constante Hardcoded, como uma Data (07/05/19), na compilação do sistema final. Sem falar no fato de que não é incomum, algumas UFs não aplicarem a exigência na mesma Data publicada... O ENCAT agiu corretamente quando definiu a exigência das novas Tags, em homologação, em uma data anterior... Isso é ótimo, pois dá tempo para as Sw.Houses se ajustarem e testarem as modificações. Porém, o ENCAT poderia definir que as novas Tags são opcionais em Produção, até a data efetiva da exigência (07/05), quando então, passariam a ser obrigatórias... Isso daria tempo necessário, para as Sw.Houses aplicarem a atualização dos sistemas nos clientes finais, a fim de garantir que a emissão de documentos em produção já esteja funcionando Algumas Tags são exigidas ou não a critério da unidade Federativa Afinal o projeto NFe é ou não nacional ? É extremamente complicado para uma Sw.House saber o que pensa cada UF individualmente... A título de exemplo, a equipe do Projeto ACBr, efetuou uma pesquisa para saber se UFs exigiriam o Grupo de Responsável Técnico e se elas iriam ou não criar um portal para cadastro e identificação das Sw.Houses (idCSRT). Consultamos TODAS as SEFAZ, usando os canais (nem sempre) disponíveis, para submeter uma consulta... O resultado pode ser conferido em nosso Mapa Fiscal mas reparem em quantas UFs não conseguimos obter uma resposta clara... Conforme pode ser acompanhado ao longos das últimas versões da NT 2018.005, a exigência do Grupo Responsável Técnico sofreu diversas alterações, culminando na prorrogação indefinida para as informações relativas IDCSRT, e para as demais informações somente as UFs de AM, MS, PE, PR, SC e TO exigirão em 03/06, as demais UFs ou optaram por não exigir ou também deixaram para data futura.* Se para cada Grupo ou Tag novo, o ENCAT continuar adicionando o famigerado texto "A critério da UF", isso é receita para o CAOS na NFe... Um projeto que até então é o orgulho dos SEFAZ, e exemplo para o mundo todo, pode se perder em um emaranhado confuso de condições, que muitas vezes não são claras... Como eu posso me prevenir ? É necessário manter os fontes do Projeto ACBr atualizados em sua máquina, e permitir que a sua aplicação tenha flexibilidade de configuração da parametrização. Ou seja, permitir que o seu Suporte Técnico possa parametrizar de maneira rápida, a geração (ou não) de novas Tags, conforme o exigido pela UF do usuário final... Já pensou por exemplo, em "descer"para o PC do cliente final, uma parametrização da "nuvem"? Mas a final, quais são as modificações ? Ok.. vamos falar um pouco sobre cada uma delas... Grupo Responsável Técnico Este grupo teve algumas prorrogações ao longo das últimas versões da NT 2018.005, porém as UFs do AM, MS, PE, PR, SC e TO optaram por manter em 03/06/19* a exigência das informações deste grupo (exceto os dados relativos ao idCSRT). Para mais detalhes sobre o assunto acesse em nossa base de conhecimento, o tópico dedicado ao assunto escrito por nosso consultor @Italo Jurisato Junior Veja também, o nosso já citado, Mapa Fiscal ICMS Substituto Estas tags vem trazendo uma série de complicações aos desenvolvedores, desde que passou a ser aplicada já em ambiente de homologação. Com a entrada em produção, será necessário a atualização dos clientes, seja com uma nova versão das aplicações ou de forma mais simples, a parametrização para gerar as tags conforme a UF do mesmo. No tópico a seguir, o consultor @EMBarbosa dá orientações valiosas para minimizar o impacto em seus clientes. Identificação do Local de Retirada e Entrega Para mais detalhes sobre o assunto acesse em nossa base de conhecimento, o tópico dedicado ao assunto, escrito por nosso consultor @Italo Jurisato Junior Ainda não acabou... dia 20/05/19 tem mais mudanças... Fique atento as mudanças previstas para o dia 20/05, que podem impactar na autorização de NFCe... O ENCAT modificou a URL de consulta do QRCode, de praticamente todos os estados, e essas novas URL já são exigidas em homologação e deverão ser obrigatórios em Produção a partir de 20/05 Leia mais sobre esse assunto, no tópico abaixo, criado pela consultora @Juliana Tamizou. *Importante: Somente a exigência do Responsável Técnico será em 03/06/19, todos os demais itens permanecem em 07/05/19, por isso não deixe de se preparar

Responsável Técnico - Como fica o XML na prática? Com tantas alterações, ficou um pouco confuso entender quando e quais tags do grupo Responsável Técnico deverão ser enviadas. Segue então um resumo. Até 02/06/2019 Os XMLs deverão ser enviados sem este grupo, como tem sido feito até então. A partir de 03/06/2019 Para as UFs do AM, MS, PE, PR, SC e TO deverá ser incluído o grupo Responsável Técnico, porém sem as tags relativas ao idCSRT. Veja imagem a seguir. Após definição de data para exigência do idCSRT Quando as SEFAZ publicarem as datas para exigência destas tags, as mesmas passarão a ser exigidas no XML, caso contrário os mesmos passaram a ser rejeitados. A seguir, exemplo de XML com o grupo Responsável Técnico completo. Importante Até o presente momento nenhuma SEFAZ disponibilizou os mecanismos para geração do idCSRT, logo mesmo em homologação não é possível enviar estas tags. A partir de 07/05/2019 as UFs que optaram pela exigência do Grupo do Responsável Técnico ( AM, MS, PE, PR, SC e TO ), já aceitaram as tags de identificação também em ambiente de produção, porém rejeitarão os XMLs sem estas tags somente em 03/06/2019.

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

O XML de retorno não contém o protocolo de cancelamento. Fazendo a consulta da chave no portal da SEFAZ consta como cancelada, com um evento com código 110112 (Cancelamento por substituição). A NT 2015.002 limitou os tipos de eventos retornados na consulta de situação para eventos de cancelamento, carta de correção e EPEC. O que deve estar acontecendo é que a SEFAZ não está tratando o evento de cancelamento por substituição como um evento a ser retornado na consulta de situação. Minha sugestão é que entre contato com a SEFAZ reportando essa situação.

Após reunião com a Secretaria de Estado da Fazenda de Santa Catarina (SEF/SC), na quinta-feira, 2 de maio, lideranças de organizações empresariais e contábeis catarinenses, conseguiram a prorrogação, em três meses, do prazo para o início da vigência do Bloco X, requisito previsto no Ato Cotepe/ICMS 9/2013, que possibilita acompanhamento e fiscalização de transações de vendas aos consumidores finais, a partir da emissão de cupons fiscais. O Ato DIAT 017/2017, publicado pela Diretoria de Administração Tributária da SEF/SC, estabelece os critérios para a obrigatoriedade de transmissão no território catarinense. Pelo calendário anterior do Fisco Estadual, o Bloco X começaria a vigorar a partir de junho deste ano. Na avaliação dos participantes presentes na reunião, a SEF/SC aceitou os argumentos apresentados pelas organizações, que apontaram as dificuldades das empresas de se adaptarem à nova sistemática, principalmente as micro e pequenas empresas (MPEs). Eles também elogiaram a postura do diretor de Administração Tributária da SEF/SC, Rogério Mello, que acatou os argumentos expostos no documento assinado por todas as entidades do setor de Comércio e Serviços. O teor do documento foi apresentado ao governador Carlos Moisés, em audiência realizada no dia 24 de abril. Confira, abaixo, o novo calendário para o início da obrigatoriedade de transmissão de arquivos fiscais, referentes cada segmento comercial: Set/2019 – Comércio Varejista - Farmácia; Jan/2020 – Comércio Varejista de Materiais de Construção; Mar/2020 – Bares, Restaurantes e Similares; Jun/2020 – demais setores. Participaram desse último encontro os representantes do Conselho Regional de Contabilidade de Santa Catarina (CRCSC); da Federação dos Contabilistas do Estado de Santa Catarina (Fecontesc); da Associação Brasileira de Bares e Restaurantes (Abrasel) - Regional Santa Catarina; e da Federação do Comércio de Bens, Serviços e Turismo de Santa Catarina (Fecomércio SC).

O componente já faz a descompactação internamente e disponibiliza o XML na propriedade ACBrNFe.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Items[ x ].XML. Também salva o XML em arquivo se configurado pra isso.

Acabou de voltar a funcionar, meu componente esta com o timeout padrao, vou criar um parametro para o cliente aumentar o tempo caso volte ocorrer.

Tópico relacionado

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:

Sim, pensei nisso... alias essa foi a decisão mais difícil... Há prós e contras... fazer um evento desse porte em SP é no mínimo 4x mais caro... (porém é bem mais rápido de vender) No fim, os fatores decisivos, para escolher o Interior, foram: O (terrível) transito de SP, e as espaçosas acomodações do Parque Tecnológico de Sorocaba

Resolvi assim: -Copiando a dll do aparelho e o arquivo SYGMASAT.INI para dentro da aplicação. Dentro do arquivo ini tem um parametro "MostraTempo=1", mude para "MostraTempo=0". Reinicie a aplicação.

Boa tarde Pessoal, Primeiro foi o CT-e e o MDF-e a ter o seu layout alterado para contemplar um novo grupo: <infRespTec> Informações do Responsável Técnico, agora esta chegando a vez da NF-e. Os 3 componentes já estão preparados para gerar esse grupo. Alguns desenvolvedores já estão gerando o grupo <infRespTec> para o CT-e e MDF-e, tanto em homologação quanto em produção. No caso da NF-e as datas previstas são: para o ambiente de homologação é 25/02/2019 e para produção é 29/04/2019 alterado para 03/06/2019 (conforme consta na versão 1.30 da NT 2018/005). Quero deixar claro que essas datas se referem ao prazo para que as SEFAZ finalizem a implementação em seus webservices, portanto somente a partir dessas datas é que poderemos enviar o XML da NF-e com esse grupo. Portanto, a partir do dia 25/02/2019 teremos um prazo de 3 meses para realizar os testes em ambiente de homologação. Outra coisa importante a ser dita é que esse grupo é opcional, mas vai ficar a critério de cada UF torna-lo obrigatório ou não. Quais são as informações que compõe esse grupo? O grupo <infRespTec> é composto pelos campos: CNPJ da empresa que desenvolveu o software, xContato é o nome da pessoa responsável pelo software, email e fone dessa pessoa ou da empresa. Caso você opte por gerar esse grupo independente da UF exigir ou não, as 4 informações acima deveram constar. Como dito acima os componentes ACBrNFe, ACBrCTe e ACBrMDFe já estão preparados para gerar o grupo <infRespTec>, para que isso ocorra basta acrescentar na sua rotina que alimenta o componente com os dados que vão fazer parte do XML as seguintes linhas... O exemplo abaixo é para a NF-e: with ACBrNFe.NotasFiscais.Add.NFe do begin (...) infRespTec.CNPJ := xCNPJ_RespTec; // CNPJ da Empresa infRespTec.xContato := xContato_RespTec; // Nome do Contato infRespTec.email := xEmail_RespTec; // email do Contato ou Empresa infRespTec.fone := xFone_RespTec; // fone do Contato ou Empresa end; As linhas em negrito acima são exatamente iguais para o CT-e e MDF-e. Nas Notas Técnicas da NF-e, CT-e e MDF-e que se refere a esse grupo tempos ainda mais dois campos: idCSRT e hashCSRT que vão ficar para uma segunda etapa. O CSRT - Código de Segurança do Responsável Técnico, trata-se de um código alfa numérico que será fornecido pela SEFAZ através de uma página própria ou por um webservice, conforme consta na Nota Técnica. Sendo assim, enquanto a SEFAZ não criar essa página ou webservice não temos como solicitar o CSRT e portanto não podemos incluir no XML o idCSRT que é um numero sequencial e o hashCSRT que é o resultado do hash (SHA1 - Base64) da concatenação do CSRT mais a chave do documento. Os componentes já possuem no rol de configurações, as propriedades idCSRT (Integer) e CSRT (String), nessa primeira etapa devemos atribuir o valor zero a idCSRT e uma string vazia para o CSRT, para que os campos: idCSRT e hashCSRT não sejam gerados. Os valores padrões estabelecidos pelo componente são: idCSRT = 0 e CSRT = '' (string vazia). Reforço que o preenchimento dessas propriedades só devem ser feitas a partir do momento que a SEFAZ lhe fornecer o idCSRT e o CSRT. Vamos supor que as UF: x, y e z venham a exigir o grupo <infRespTec> e criem uma pagina ou webservice para fornecer o CSRT, caso você tenha clientes usando ou seu software para emitir NF-e ou CT-e ou MDF-e será necessário solicitar o CSRT em cada uma das UF. Resumindo o CSRT fornecido pela UF x só é valida para os seus clientes dessa UF que usam o seu software. Quais são as UF que vão exigir o grupo <infRespTec> não sabemos, logo devemos ficar atentos. A minha sugestão é que o seu software gere esse grupo independente da UF exigir ou não, pois o dia que ela resolver exigir você não vai precisar fazer nada, pois já consta no XML o grupo. A questão agora é quanto ao CSRT, como dito anteriormente, vai ficar para uma segunda etapa visto que, se faz necessário a SEFAZ criar a página ou webservice. O meu conselho é que no seu software na tela de configuração tenha os campos: idCSRT e CSRT para que você possa informa-los assim que obter. Detalhe importante, os campos idCSRT e hashCSRT só serão gerados no XML e de forma automática dentro do grupo <infRespTec> a partir do momento que as propriedades de configuração: idCSRT e CSRT passarem a ter valores validos. O texto ficou longo, mas espero ter passado todas as informações necessárias para que vocês possam fazer as alterações em seus softwares e desta forma ficarem em conformidade com as nas Notas Técnicas. Para quem não leu as NT, por favor leiam. NT 2018/005 versão 1.20 - Alteração do layout da NF-e https://sourceforge.net/p/acbr/code/HEAD/tree/tools/DFe/NFe/NT/2018/ NT 2018/002 versão 1.01 - Alteração do layout do CT-e https://sourceforge.net/p/acbr/code/HEAD/tree/tools/DFe/CTe/NT/2018/ NT 2018/002 versão 1.02 - Alteração do layout do MDF-e https://sourceforge.net/p/acbr/code/HEAD/tree/tools/DFe/MDFe/NT/2018/

Boa tarde Pessoal, procurei pelo conteúdo no fórum e não encontrei algo específico, então caso haja algo do tipo por favor ignorem... Estou com uma demanda nova de um cliente, e vi que não temos nada no acbr até então, ou seja, decidi iniciar um projeto e apresenta-lo aos senhores, porém não vi nenhuma documentação do acbr referente a seguir algum padrão, ou algum modelo de componente para seguir, afim de auxiliar a compreensão de todos no futuro. há algo referente a isso? e como faço para iniciar um novo projeto e incorpora-lo ao acbr? grato pela atenção.

Olá a todos, Fui surpreendido com a notícia do erro "Endereço do site da UF de Consulta por chave de acesso diverge do previsto" e todos os meus clientes serão impactados dia 20-05-2019. Mas dado a dica da Juliana, bastou colocar o ACBrNFeServicos.ini atualizado no mesmo diretório do meu aplicativo e parou de dar o erro em ambiente de homologação. Só que a única mudança que vi no XML referente ao QRCode foi em uma tag chamada <urlChave>, sou do Rio, antes o endereço vinha com "http://", mas agora vem SEM o "http://"... É realmente só essa mudança e só nessa tag mesmo que estava gerando esse erro? Desde já agradeço a atenção de todos

Vou responder suas dúvidas, mas vou fazer isso no final, porque quero esclarecer algo importante. Suas dúvidas me parecem esbarrar mais na ideia de um "representante da classe de programação" perante a lei do que de um responsável pelo sistema. Talvez isso tenha acontecido porque o termo usado é "responsável técnico". Mas veja bem, o responsável técnico é a pessoa para quem a Sefaz vai mandar um e-mail quando quiser falar sobre o software emissor da NF-e. Talvez queira recordar esse tópico onde explico o motivo porque não se pode colocar o projeto ACBr como responsável técnico: As ideias são as mesmas. Dito isso, vamos a suas perguntas: Depende mais do tipo do vínculo entre eles e menos de ser uma pessoa física. A questão que deve ser respondida é: Quem é o responsável pelo software? Quem a SEFAZ deve contatar caso queira falar sobre o sistema? Isso vai depender de cada caso e de cada UF. Então algumas perguntas podem ajudar a responder. O sistema é atualmente da ME distribuidora de produtos de limpeza? O programador é chamado como um terceirizado ou mesmo como funcionário temporário da empresa, não tendo de fato vínculo com o sistema? Por exemplo, ele pode ser substituído por outro programador? (Note, não importa aqui o conhecimento interno do sistema...) Se a resposta a essas perguntas for sim então, a menos que algo diferente esteja em contrato, o responsável técnico é a empresa distribuidora de produtos de limpeza. Ela contrata outra pessoa para dar manutenção mas, ainda assim, ela é responsável, porque o sistema é dela. No PAF-ECF, chamávamos isso de "sistema próprio". Quer dizer próprio da empresa. Caso a resposta para as perguntas forem não, então, provavelmente, o responsável técnico é o programador e será necessário verificar com a UF como ele deve ser informado já que ele não tem CNPJ. Nesse caso, sem dúvida o responsável técnico é a própria empresa. Ela tem um sistema próprio, desenvolvido internamente para emitir os DF-e. Não importa se quem faz as alterações é programador ou o contínuo. O importante é quem é responsável perante a SEFAZ e, nesse caso, é claro que a SEFAZ não vai querer saber quem deu manutenção no sistema. Quando ela precisar falar com um responsável, ela vai querer contatar diretamente a empresa. Afinal de contas, se a empresa não quisesse isso ela teria contratado um sistema de alguém ao invés de permitir um funcionário (ou sobrinho do dono) criar o sistema. Espero ter sido de ajuda.

Boa tarde. Deve sim estar já com as novas regras implementadas, porém do jeito que andam as coisas, certeza somente testando ou acionando o suporte da SEFAZ-SP. Att.

Boa tarde. De acordo com este documento fornecido pelo ENCAT, no RJ não são exigidas estas tags. http://nfce.encat.org/desenvolvedor/regras-de-validacao/ 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.

Boa tarde. Sim amigo são dos emitentes! Onde você tiver cliente, (emitente) será necessário a implementação de tal tag. Veja o mapa https://www.projetoacbr.com.br/acbr-mapas-fiscais/#acbrmapa_responsavel_tecnico

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

Olá, gostaria de deixar aqui o link para uma pesquisa sobre desenvolvimento de sistemas, quem puder preencher ficaria muito agradecido: https://forms.gle/iPEEvBxKGUcmTzse8

Tive problemas em SP (Erro HTTP 403) e em MT ( Erro 12030). Acredito que deva ser algum problema no SEFAZ, não sei se os clientes tentaram enviar as notas novamente. Assim que tiver algum retorno eu posto o resultado.

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.

resolvido era o unit dbutil

obrigado Felipe vou testar assim que estiver na empresa, depois aviso como ficou. grato por enquanto

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

Bom dia. Esta informação foi prorrogada por tempo indeterminado, somente os dados de identificação serão exigidos no momento. Att.

Deu certo obrigado pelas dicas, caso alguém necessitar de maiores informações estou a disposição.

Bom dia, Notei nas suas configurações do ACBrMonior que está marcado na tela inicial a opção: "Mostrar Linhas do Log na Tela em Respostas Enviadas", esta opção realiza a leitura de todo o log e adiciona em tela e realmente pode deixar lento o processo se obter uma resposta muito grande. Experimente desmarcar essa opção...

Bom dia Verifique se o dígito da conta não está com um dígito a mais ou com espaço em branco... De qualquer forma vamos adicionar uma validação para este campo, parece ser o único campo sem validador de tamanho.

Boa noticia, ganhamos um pouco mais de tempo. Mesmo assim ainda se faz necessário ajustar o ACBr Monitor para envio dos novos métodos do webservice. Posso tentar ajudar no que for possível.

Na linha abaixo FPDFeOwner.Integrador.Parametros.Values['versaoDados'] := '4.00';

Boa tarde, Conforme consta no Log que você anexou a execução dos comandos foram realizadas em questão de segundos. 03/05/2019 15:35:54 - NFe.DistribuicaoDFePorUltNSU(SP,12554744000137,000000000000000) 03/05/2019 15:36:17 - OK: 03/05/2019 15:39:27 - NFE.StatusServico 03/05/2019 15:39:29 - OK: Servico em Operacao Agora o tempo entre um comando e outro ser de 3 minutos e 33 segundos, deve ser o tempo gasto pelo ACBrMonitor para gerar o retorno, pois o primeiro comando retornou 50 documentos (Resumos de notas, notas completas, resumos de eventos, eventos completos).

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

Poxa Daniel que excelente notícia. Isso, será muito importante para nós, estamos desenvolvendo um software de gestão em java e atualmente integramos ele com o ACBRMonitorPlus, mas seria muito mais interessante termos todas as vantagem que o ACBR tem de forma nativa "Classes". Aguardaremos ansiosamente.

Desde segunda feira mudou para 30 minutos o prazo de cancelamento de NFC-e Depois deste prazo tem 168 horas para fazer um Evento de cancelamento por substituição

Era esse o problema mesmo. Obrigado Juliana!

Olá Willian, Ao analisar o código eu notei as seguintes características. Precisava que você comentasse antes de a gente incluir no projeto ACBr: A unit GerarBlocos.pas está vazia e não é utilizada por nenhum arquivo. Poderia avaliar se não está faltando nada? O componente não está utilizando nenhuma das classes do ACBrTXT. Isso foi proposital? Os registros estão definidos usando Generics. Como nosso projeto atualmente suporta o Delphi 7, talvez tenhamos que alterar os tipos. Vê algum problema nisso? Por último, mas mais importante: Notei que nenhum arquivo tem a licença anotada, mas na procedure de registro está o nome de uma empresa. Você confirma que esses fontes são de sua autoria e podem ser licenciados como LGPL ou MPL, alterados e adicionados ao projeto seguindo as licenças do ACBr?

Boa tarde, testei com essas e também com outras encontradas na internet. Vou entrar em contato com eles da Secretaria, e conferir o que pode ser.

Olá Felipe. Perfeito, fiz teste com nota emitida em ambiente de homologação e passou. Muito obrigado..

obrigado, BigWings ! Otavio Benini

O SCAN não é mais usado, foi desativado há tempos. Se a SEFAZ agendou a contingência o que vai ser ativado vai ser a contingência SVC. Para saber como tratar a contingência leia o manual de orientações do contribuinte, a partir da página 150: http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=URCYvjVMIzI= No caso de SP a SEFAZ usa a SVC-AN para autorização em contingência: O que precisa fazer na aplicação: - Ajustar a configuração ACBrNFe.Configuracao.Geral.FormaEmissao := teSVCAN; - Na geração da NFe informar a tag tpEmis = teSVCAN; O restante do processo é como no envio normal, a NFe é enviada para o webservice de contingência e ele fornece o protocolo de autorização. Nada mais é preciso fazer do lado da aplicação, assim que o serviço da SEFAZ for normalizado, o próprio webservice se encarrega de sincronizar as NFe emitidas em contingência.

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

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

A ideia era permitir a Sw.House distribuir com o sistema, todas as DLLs suportadas, na mesma pasta do EXE... e o próprio componente verificaria quais modelos estão disponíveis, com uma chamada ao método de Classe TACBrPosPrinterHook.CanInitilize Incorporar esse ajuste, quebraria essa funcionalidade... Você não poderia definir outro valor na porta ? Como por exemplo "NONE"

Olá Willian, Encontrei esse aplicativo no site da Receita. Ele não serve como validador dos dados ou estrutura?

Livro caixa digital do produtor rural. http://receita.economia.gov.br/orientacao/tributaria/declaracoes-e-demonstrativos/lcdpr-livro-caixa-digital-do-produtor-rural Sobre isso aqui ?

Instabilidade no site da Receita. Pelo site na opção de "Captcha Sonoro" (link que é usado pelo ACBr) também não funciona. O jeito é aguardar normalizar.