Painel de líderes

Pessoal, Reforçando a informação, qualquer retorno diferente do demonstrado abaixo não esta dentro do previsto, deve-se contatar o suporte técnico da Tanca no link acima com o log do equipamento, caso ja tiverem ticket aberto na plataforma informar diretamente para o e-mail [email protected], irei agilizar a resposta. 20190228174006|SAT-SEFAZ|info|Acessando CFeConsultaGestao (obtendo todos os parametros) 20190228174007|SAT-SEFAZ|info|CFeConsultaGestao[id:1]: wssatsp.fazenda.sp.gov.br:443 20190228174007|SAT|info|Codigo de resposta do WS: 200 20190228174008|SAT|info|Recebido arquivo de vigência de leiaute. 20190228174008|SAT|info|Recebido arquivo da tabela ANP. 20190228174008|SEFAZ-SAT|info|CFeConsultaGestao: [133] Solicitação de dados efetuada com sucesso

É só você colocar essas informações no campo de observações.

Em MG, a contingencia para NFC-e será a própria NFC-e, bastando mudar o tipo de emissão para Offline, informar a justificativa e por fim imprimir. E, após o serviço da SEFAZ se restabelecer, enviar a mesma.

Boa tarde. Iniciamos um trabalho de pesquisa junto a todas as SEFAZ , porém o retorno está um pouco lento. Você pode acompanhar estas informações em nosso Mapa Fiscal referente ao Grupo de Responsável Técnico. https://www.projetoacbr.com.br/acbr-mapas/#acbrmapa_responsavel_tecnico Att.

Boa tarde, Eu realmente fui procurar a nota técnica aqui e já enviei o embasamento legal para o cliente. Muito obrigado. É uma alternativa, vou propor isso ao cliente. Obrigado

Boa tarde, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Identificamos algumas correções necessárias na unit "ACBrEFDBloco_B_Class.pas" para geração do Bloco B: - Os campos de Valor do Registro B020 são obrigatórios (removido o True para permitir que venha null); - O segundo campo do Registro B440 (IND_OPER) deve ser preenchido com 0 ou 1, sem decimais (o manual está errado); - Ficou faltando o preenchimento do campo VL_SUB do Registro B470. Segue em anexo o arquivo para avaliação. ACBrEFDBloco_B_Class.pas

Obrigado já está no svn

Bom Dia, Ao utilizar o "DANFE_Paisagem_2019.fr3" para impressão Fast ocorria o erro "Erro(s) encontrado(s): Erro no script em 84:29: Identificador não declarado:'QuadroCanhotoEsquerdaNFe'" realizei o ajuste e algumas melhorias em alguns quados como o Município e UF do transportador. anexo segue a correção do modelo. DANFePaisagem_2019.fr3

No SVN : 16673 Grato.

Em análise. Grato pelo contribuição

Bom Dia Pessoal estou gerando o sped contribuições na versao 310 e esta dando erro ao importar para o validador... esta dizendo que o numero de campos esta errado... pelo validador esta constando que deveria ter 13 e esta sendo montando pelo acbr com 16... como proceder ? desde ja agradeço a ajuda de vcs segue arquivo para analise... att Tiago Passarella EFDContribuicoes-09654587000127-FEVEREIRO-2019.txt amigos me perdoem pelo vacilo... validador desatualizado... att Tiago Passarella

Opa, beleza, Não tinha atualizado. Vou fazer isso após almoço e recompilo tudo. Obrigado pelo retorno.

Obrigada, Cléber. Isso que eu queria saber.

Italo, segue todos os procedimento que você solicitou. Porem entrei em contato com a SEFAZ novamente e elas ficaram de verificar. Passando a funcionar corretamente (Acho que o problema era realmente da SEFAZ)

Correto irmão @Juliomar Marchetti participo na medida do possível nos testes e sugestões de melhoria. Agradeço a prontidão na solução dos problemas. Esse aqui, é mais um, que foi prontamente resolvido.

Experimente marcar a opção ACBrNFe1.Configuracoes.Arquivos.SalvarApenasNFeProcessadas.

bom dia.. https://acbr.sourceforge.io/ACBrMonitor/Apresentacao.html https://acbr.sourceforge.io/ACBrMonitor/ComandosdoObjetoNFENFCe.html Entre nesse links, e de uma olhada.. O AcbrMonitorPlus é muito simples. voce vai criar arquivo txt e ele vai gerar os xml para voce. estou mandando um exemplo em txt, e o xm que ele gera txt_pag.txt xml_pag.xml

Já baixou o instalador? já leu o arquivo de help? já pesquisou aqui no fórum as dúvidas que surgiram?

As configurações estão corretas... Verifique se a propriedade SSLType está setada como: LT_TLSv1_2, precisa utilizar sempre essa. Os componentes ACBr o recomendado é que estejam sempre atualizados. Como a configuração Wincrypt utiliza dlls do Windows o mesmo precisa estar atualizado também.

bom dia.. Uma soluçao seria voce ver se no xml tem a tag infProt

Bom dia.. Não esta sendo informado o horario. Quando gerar o xml novamente e enviar, mande tambem o xml com o retorno do erro ou o log de retorno.

Sim.

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.

Boa tarde, Professor. Tente fazer da seguinte forma: Enviar CPF no lugar do CNPJ do emitente e usar a série que o SEFAZ reservou para esta nota. Lembrando que você vai precisar de um certificado do tipo e-CPF. Veja também o link abaixo: https://www.projetoacbr.com.br/forum/topic/48778-nota-fiscal-eletronica-produtor/

Boa tarde Marciano, Complementando a resposta do Junior, só podemos imprimir no DACTE informações que estejam presente no XML do respectivo CT-e, isso consta no manual. Portanto imprimir informações que não existe no XML é passivo de um puxão de orelha ou algo pior do Fisco.

Sim chama o contador e pede pra se virar ele que errou no credenciar. outra coisa essa versão já tem a informação do responsável técnico? senão pode contribuir para o problema

Boa tarde, Seguindo as especificações da NT CTE 3.0 alguns campo não são mais informados no CTe e sim no MDFe, no caso dos dados do motorista e veículo está nessa situação. Por isso não gera essas informações a partir da versão 3.0

Vou entra em contato com o provedor deles. Italo, Muito obrigado pela ajuda.

Bom dia Maikon, Uma coisa é o XML do RPS, que é gerado e enviado para o webservice pelo componente. Nesse XML no que diz respeito ao Prestador só é informado o CNPJ e a IM. Outra coisa é o XML da NFS-e, que é gerado e retornado pelo webservice. O XML da NFS-e é para constar todos os dados do Prestador. É o XML da NFS-e que devemos utilizar para imprimir o DANFSE.

Flávio, Como você deve notar no arquivo 456-rec.xml e nele que contem a mensagem que a licença não é valida ou tenha expirado. Que eu saiba nenhum provedor existe que a aplicação do contribuinte tenha uma licença para consumir o webservice. O que os provedores costumam exigir é um cadastro especifico para usar o webservice. O que pode esta ocorrendo: 1. A prefeitura mudou de provedor; 2. O certificado digital do provedor venceu, neste caso a mensagem de erro esta errada. 3. O cadastro para o contribuinte continuar usando o webservice é preciso ser renovado. Favor entrar em contato com o provedor para saber o que realmente esta ocorrendo.

Bom dia Samuel, Pelo que entendi a cidade de Caldas Novas/GO mudou de WebISS para WebISSv2. Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

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

Bom dia Tathiana, Alem de atualizar os fontes, reinstalar os componentes, esta usando o arquivo INI novo do respectivo provedor?

Bom dia Junior, Pelo jeito você não chegou a atualizar mais os seus fontes após o dia 6, pois esse erro foi detectado e corrigido. Favor atualizar todos os fontes de todas as pastas e reinstale novamente os componentes.

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

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

Bom dia Edmar, Muito obrigado pela correção, já enviei para o repositório.

Bom dia Adélio, Muito obrigado pela colaboração, já enviei para o repositório, mas fiz uma pequena alteração, favor testar.

Mesmo após o prazo de 24 horas o XML será acatado com o cStat 150 (Autorizado fora do prazo). Nada mais precisa ser feito, o único porém é que a SEFAZ pode vir a pedir explicações pelo atraso.

Bom dia Cesar, É interessante você informar como o problema foi resolvido. Você poderia nos contar?

Bom dia, os fontes estão atualizados? Houve um ajuste recente para casos parecidos... Verifique se o código original no e-mail está como: Conten- Disposition : Attachment

Bom dia Italo, O problema com a Bahia foi resolvido. Enviado cancelamento com substituição normalmente. Muito Obrigado.

Esse componente foi descontinuado e não é mais mantido pelo Autor original... Mantivemos o mesmo no ACBr, apenas por questão de compatibilidade

boa tarde, é possivel definir a pasta onde sera gerado o xml que sera enviado. o O demo exemplifica

Bom dia.. Mande o Xml gerado para analise..

Aparentemente teu sistema não esta preenchendo corretamente a propriedade do NCM no item... Analise denovo esse ponto no teu código... Att Ricardo

Tive o mesmo erro aqui, em tempo de design ao clicar na aba testes ocorre a exceção. Mesma versão do Lazarus do @jcdatrindade. Consegui isolar o erro no componente mResposta, removendo o trecho a seguir, ele não ocorre mais. Não sei a que se refere esta propriedade, espero que ajude.

Bom dia Thiago, Te aconselho, nesse período de transição emitir em ambiente de homologação no sistema novo. Se você mudar de série a numeração vai iniciar do 1. Como você vai fazer para explicar para a SEFAZ os CT-e que não foram emitidos da outra versão? O sistema atual se utiliza da serie 1 e a numeração se encontra em 50.000 O novo vai utilizar a serie 2 com numeração inicial 1. Após o processo de transição o sistema atual para na numeração 50.500, sabendo que a numeração de uma serie varia de 1 até 999.999.999 o que você vai dizer para a SEFAZ porque não emitiu os CT-e de 50.501 até 999.999.999 da série 1? Pense um pouco mais sobre isso.

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/