Italo Giurizzato Junior

Boa tarde Ariane, Impossível. Favor anexar o XML da nota que foi rejeitada.

Boa tarde Everton, Se o destinatário é uma pessoa jurídica, porque no pedido de evento consta o CPF? Deveria ser o CNPJ do destinatário e o pedido ser assinado com o certificado digital com o mesmo CNPJ.

Bom dia, De onde você tirou essa ideia de criar um numero sequencial para o cNF? Sendo que a recomendação da SEFAZ é que o cNF seja um numero aleatório. Qual é a dificuldade de você criar na tabela que contem os dados da nota, um campo a mais para armazenar o código da nota gerado aleatoriamente pela função que criamos? É complicado na rotina que alimenta o componente, você ler da tabela essa informação e atribuir ao campo cNF como é feito com os demais campos? Por favor, me responda qual é a dificuldade, pois até agora eu não entendi. Desde de 2009 (ou até antes) a orientação da SEFAZ é que o código da nota seja um numero aleatório. Será que é tão difícil entender o motivo?

Bom dia a todos, Pelo que eu entendi o emitente da nota é uma pessoa física, logo esta usou um certificado digital que contem o CPF da mesma. O destinatário da nota é uma pessoa jurídica, logo possui um CNPJ. Quem esta enviando o evento de Manifestação do Destinatário? Pelo tipo de evento tem que ser o Destinatário, se este é uma pessoa jurídica ela tem que estar usando o seu certificado digital que contem o CNPJ. Favor anexar o XML de pedido do evento, bem como o seu retorno.

Rosenildo, A sua aplicação esta usando um Schema antigo que contem a tag pICMSInterPart. Favor utilizar os Schemas da pasta: ...\Exemplos\ACBrDFe\Schemas\CTe

Rosenildo, Os campos: vBCUFFim, pFCPUFFim, pICMSUFFim, pICMSInter, vFCPUFFim, vICMSUFFim, vICMSUFIni devem ser calculados supondo que o valor de vICMSInterPart seja 100. Mas devemos atribuir o valor zero a vICMSInterPart para que essa tag não seja gerada no XML. Favor atualizar todos os fontes de todas as pastas, reinstale a suíte ACBr e recompile a sua aplicação. Por fim faça novos testes.

Eptus, Favor entrar em contato com o próprio provedor, ele tem a obrigação de informar a URL correta para a cidade em questão.

Bom dia Rosenildo, O seu XML não contem o grupo infCTeSupl que contem a tag qrCodCTe com a string do qr-Code. E no grupo ICMSUFFim ainda esta sendo gerado a tag pICMSInterPart com o valor 100. Essa tag não deve mais ser gerada, portanto faça os cálculos como se ela tivesse o valor 100, mas atribua o valor zero a ela.

Bom dia Eptus, Pela mensagem de erro o problema não é o cancelamento e sim a consulta a NFS-e por RPS que é realizada em seguida que esta ocorrendo o erro. O erro 400 se não me falha a memória significa que a URL esta errada.

Bom dia Jhonlenon, Você esta alimentando os campos do grupo: ICMSUFFim ?

Bom dia Marcelo, No meu entendimento a foto deve ser armazenada sim em disco ou no banco de dados, pois é uma "informação" que foi utilizada para compor o conteúdo do hashEntrega que foi enviado para a SEFAZ.

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

Boa noite Claudio, Favor anexar o XML do CT-e.

Boa tarde Kaio, Se o provedor ISSDSF agora vai seguir a versão 1 do layout da ABRASF, devemos criar um novo arquivo INI e fazer os devidos ajustes no componente e não fazer alteração no arquivo GINFES.ini só pelo fato deste também seguir a versão 1.

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

Boa tarde Nilton, Maravilha o grupo CpfCnpj aparece dentro dos grupos: LoteRps, Prestador e InformacaoTomador. Em qual dos 3 não deve consta o grupo CpfCnpj?

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

Boa tarde @Fabio Fernandes da Silva, A empresa DSF (que chamo de provedor) agora possui um webservice que segue a versão 1 do layout da ABRASF, isso confere? Se sim, vamos ter que criar um novo arquivo INI. Hoje temos o ISSDSF.ini que é utilizado pelo provedor ISSDSF cujo layout é próprio. Devemos então criar o DSFv1.ini e um novo enumerador chamado proDSFv1 para indicar que esse provedor segue a versão 1 do layout da ABRASF. Se a resposta da minha pergunta cima for SIM, gostaria que você anexasse aqui no fórum os schemas, bem como as URLs de homologação e de produção das cidades que vão ser atendidas por esse novo webservice. Se seria de grande ajuda o layout dos Envelope de envio, consulta, etc.

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

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

Boa tarde Rogério, Movi a sua postagem por ter postado em lugar errado (ACBrMDFe se refere ao componente de Manifesto de Documentos Fiscais Eletrônicos e não Manifestação do Destinatário que é um evento). Por favor preste mais atenção onde postar, pois você poderá ficar sem a resposta. Ao enviar o evento de Manifestação do Destinatários dessas notas que não foi liberado o XML para Download, o evento foi registrado com sucesso?

30/08/2019 ATENÇÃO: Publicada a versão 1.30 da NT 2019.001 Publicada a versão 1.30 da NT 2019.001, que divulga novas regras de validação e atualiza regras existentes da NF-e/NFC-e versão 4.0, com os seguintes objetivos: • Informados os locais de publicação das tabelas de códigos de benefícios fiscais e de regras de validação opcionais por unidade federada • Novas datas de vigência para algumas regras de validação Publicada a tabela cBenef x CST atualizada até 30/08/2019 Assinado por: Coordenação Técnica do ENCAT Informações importantes nessa nova versão: 1.7 Comentários Sobre o Código de Benefício Fiscal O código de benefício fiscal (tag: cBenef), por tratar de situações particulares de cada unidade federada, tem sua definição também especificada pelas UF que o utilizam. Estas definições constam de tabela publicada no Portal Nacional da NF-e, na área “Diversos” da aba “Documentos”. Esta tabela tem sofrido atualizações com frequência maior do que a desejável, em virtude do fato que o uso dos códigos pelas empresas no ambiente de homologação tem evidenciado a necessidade de ações de correção de natureza emergencial por parte das Administrações Tributárias envolvidas. É esperado que em futuro próximo a tabela tenha a estabilidade necessária. 1.8 Novas Datas de Vigência para Algumas Regras de Validação Em função de necessidades ditadas pelas legislações de algumas unidades federadas, e atendendo a pleitos de contribuintes e de entidades associativas, as datas de início de exigência das regras de validação N12-85, N12-86, N12-90, N12-94 e N12-97 obedecerão ao disposto na tabela a seguir: UF Regra de validação N12-85 N12-86 N12-90 N12-94 N12-97 MT (3) (3) (2) (3) (*) PR (1) (1) (*) (2) (1) RJ (2) (2) (2) (2) (2) RS (2) (2) (2) (2) (2) demais UF (*) (*) (*) (*) (*) Onde a respectiva data de início de vigência corresponde a: (*) Regra de validação não será aplicada (1) Aplicação a partir de 02/09/2019 (2) Aplicação a partir de 01/10/2019 (3) Aplicação a partir de 01/01/2020 As datas aqui definidas, juntamente com todas as demais informações a respeito das regras de validação opcionais por UF, podem ser consultadas em tabela publicada no Portal Nacional da NFCe, na área “Regras de Validação” da aba “Desenvolvedor”. Para contribuintes estabelecidos no estado do Rio Grande do Sul, no caso das regras N12-85, N1286 e N12-94, o ambiente de autorização em produção, até 31/3/2020, e o ambiente de autorização em homologação até 09/2/2020, aceitarão três situações para o campo cBenef:  NULO (sem preenchimento do campo);  com a descrição "SEM CBENEF"; ou  com o código do benefício; neste último caso, é realizada a devida validação de compatibilidade com o CST informado.

Boa tarde Igor, Com certeza é alguma kaka da SEFAZ.

Boa tarde Marcos, O valor tpNenhum foi criado para fazer com que o grupo infFretamento não seja gerado, visto que ele é opcional.

Bom dia Lucas, Favor anexar o XML.