Painel de líderes
Conteúdo popular
Showing content with the highest reputation on 11-03-2019 em Posts
-
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 sucesso3 pontos
-
É só você colocar essas informações no campo de observações.3 pontos
-
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.3 pontos
-
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.3 pontos
-
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. Obrigado2 pontos
-
Boa tarde, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.2 pontos
-
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.pas2 pontos
-
2 pontos
-
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.fr32 pontos
-
2 pontos
-
2 pontos
-
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 Passarella2 pontos
-
Opa, beleza, Não tinha atualizado. Vou fazer isso após almoço e recompilo tudo. Obrigado pelo retorno.2 pontos
-
2 pontos
-
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)2 pontos
-
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.2 pontos
-
Experimente marcar a opção ACBrNFe1.Configuracoes.Arquivos.SalvarApenasNFeProcessadas.2 pontos
-
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.xml2 pontos
-
Já baixou o instalador? já leu o arquivo de help? já pesquisou aqui no fórum as dúvidas que surgiram?2 pontos
-
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.2 pontos
-
2 pontos
-
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.2 pontos
-
2 pontos
-
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.1 ponto
-
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/1 ponto
-
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.1 ponto
-
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 problema1 ponto
-
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.01 ponto
-
1 ponto
-
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.1 ponto
-
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.1 ponto
-
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.1 ponto
-
Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.1 ponto
-
Bom dia Tathiana, Alem de atualizar os fontes, reinstalar os componentes, esta usando o arquivo INI novo do respectivo provedor?1 ponto
-
Bom dia Giovanni, Veja os XML gerados pelo programa exemplo. NFSe.rar É obvio que o RPS foi rejeitado, pois utilizei um CNPJ de uma empresa que não é do Rio de Janeiro.1 ponto
-
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.1 ponto
-
Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.1 ponto
-
Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.1 ponto
-
Bom dia Edmar, Muito obrigado pela correção, já enviei para o repositório.1 ponto
-
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.1 ponto
-
Bom dia Cesar, É interessante você informar como o problema foi resolvido. Você poderia nos contar?1 ponto
-
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 : Attachment1 ponto
-
Bom dia Italo, O problema com a Bahia foi resolvido. Enviado cancelamento com substituição normalmente. Muito Obrigado.1 ponto
-
1 ponto
-
Esse componente foi descontinuado e não é mais mantido pelo Autor original... Mantivemos o mesmo no ACBr, apenas por questão de compatibilidade1 ponto
-
boa tarde, é possivel definir a pasta onde sera gerado o xml que sera enviado. o O demo exemplifica1 ponto
-
Aparentemente teu sistema não esta preenchendo corretamente a propriedade do NCM no item... Analise denovo esse ponto no teu código... Att Ricardo1 ponto
-
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.1 ponto
-
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/1 ponto
-
Boa tarde pessoal. Acredito que a maioria de vocês já tomou conhecimento dos novos planos de contratação do SAC ACBr, alguns usuários também podem ter notado que a carência para pagamento após o fim do período de vigência do SAC deixou de existir. Esta carência era uma herança dos tempos em que os boletos eram emitidos diretamente por nós, e com a utilização do PagSeguro deixou de ser necessária e desta forma foi removida. Desta forma temos o seguinte funcionamento: Após confirmação do pagamento pelo PagSeguro, o acesso ao SAC é liberado pelo número de dias corridos, correspondente ao pacote contratado, quando restarem 10 e 3 dias para o término da vigência do contrato, são enviados emails notificando o usuário e com as orientações para a renovação do contrato. Notas Importante: Você não precisa efetuar o pagamento quando receber estas notificações, porém vale lembrar que conforme o meio de pagamento utilizado, o processo até a confirmação de pagamento pode levar alguns dias, portando deixar para o limite pode não ser uma boa ideia. Ao realizar a renovação antecipada da assinatura, você não perde os dias restantes da assinatura atual, uma vez que os dias referentes a renovação serão acrescidos ao saldo atual Ao criar em seu financeiro o planejamento para realizar a renovação no primeiro aviso, ou seja, restando 10 dias para o término da vigência de seu contrato, você garante a continuidade do serviço SAC e cria automaticamente o intervalo de 30 dias (90, 180 ou 365 conforme plano escolhido) para realização de novo pagamento. Exemplo de fluxo de contratação Afim de lhes auxiliar a entender as notificações enviadas no decorrer da vigência de sua assinatura, elaboramos o fluxo abaixo: Situação SAC Anterior ao pagamento: Não era assinante/assinatura cancelada Data de Ativação do SAC após confirmação do PagSeguro: 22/11/2018 Plano Contratado: Mensal (30 dias corridos) 1. Após nosso sistema receber a notificação de confirmação de pagamento do PagSeguro, seu acesso SAC é liberado número de dias corridos correspondente ao plano contratado, em nosso exemplo 30 dias. É enviado notificação ao usuário tanto para o email da conta como para o email de cobrança, conforme exemplo a seguir. 2. No dia 13/12/18., quando restam 10 dias de vigência do pacote contratado, é enviada notificação com orientações para que seja possível realizar a renovação do seu pacote (caso seja de seu interesse efetuar o pagamento neste momento). Importante: Caso opte por realizar o pagamento neste momento você não perderá dias da assinatura em vigor, pelo contrário, serão acrescidos os dias referentes ao novo pacote contratado. Em nosso exemplo, a vigência passaria a ser até 21/01/2019. 3. Caso você tenha optado por aguardar mais tempo para realizar a renovação do seu pacote SAC, no dia 20/12/2018 quando restarem 3 dias para o final do período de vigência, você receberá um e-mail semelhante ao anterior, porém agora informando que restam somente 3 dias até o fim de seu pacote. Importante: Caso opte por realizar o pagamento neste momento você não perderá dias da assinatura em vigor, pelo contrário, serão acrescidos os dias referentes ao novo pacote contratado. Em nosso exemplo, a vigência passaria a ser até 21/01/2019. 4. No dia 23/12/2018, caso nosso sistema não acuse nenhuma notificação de pagamento realizado por meio do PagSeguro, sua assinatura automaticamente estará cancelada. Neste caso você pode optar por reativar sua assinatura em sua SAC em SAC ACBr-> Meus Dados Veja também... Caso ainda tenha dúvidas, fique a vontade para nos contatar [email protected] Att.1 ponto