Italo Giurizzato Junior

Bom dia Udenilson, Muito estranho essa resposta. Se o RPS foi enviado e convertido em NFS-e, depois a mesma é cancelada, no meu entendimento qualquer método que retorne o XML da NFS-e deveria constar que a mesma esta cancelada. Sugiro você entrar em contato novamente com o provedor e questionar isso. Qual é a razão de um método retornar o XML da NFS-e sem as informações de cancelamento sendo que a nota esta cancelada e em outro retornar.

Boa tarde Kelvin, Muito obrigado pela colaboração, vou incluir na minha lista de tarefas.

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

Boa tarde, Não existe Ordem de Coleta Eletrônica a ser enviada para SEFAZ. O que existe é o grupo <occ> dentro do grupo <rodo> onde você informa os dados referente a ordem de coleta, detalhe um CT-e pode conter até 10 <occ>. Conversa direito com ele, talvez o que ele quer é que a transportadora informe as coletas no CT-e.

Boa tarde Edu, Tenha em mente que o modelo 57 se refere ao CT-e = Conhecimento de Transporte Eletrônico, utilizado para acobertar o transporte de cargas. Já o modelo 67 se refere ao CT-e OS = Conhecimento de Transporte Eletrônico Outros Serviços, utilizado par acobertar o transporte de valores, bagagem extra ou fretamento. O método de envio é o mesmo, mas por conta das particularidades dos dois modelos a rotina que alimenta o componente são diferentes.

Boa tarde, Chegou a verificar se em nenhuma outra unit da sua aplicação essa configuração é alterada?

Boa tarde Rogerio, Por favor anexe o XML do CT-e gerado pelo Monitor.

Boa tarde, Você poderia anexar um XML de NFS-e retornado pelo provedor Elotech, pois achei estranho a sua rotina que faz a leitura desse XML. Desde já muito obrigado.

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

Boa tarde Igor, Já enviei para o repositório.

Boa tarde Danilo, Muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde Jefferson, Eu não utilizo o ACBrMonitor, mas procurei no manual do mesmo o método para imprimir o DANFE e encontrei a seguinte sintaxe. NFE.ImprimirDanfe(cArqXML,[cImpressora],[nNumCopias],[cProtocolo],[bMostrarPreview],[cMarcaDagua],[bViaConsumidor],[bSimplificado]) Parâmetros cArqXML - Caminho do arquivo XML da NF-e. cImpressora - Nome da Impressora. Obs.: Parâmetro opcional. nNumCopias - Número de Cópias. Obs.: Parâmetro opcional. cProtocolo - Número de Protocolo de NF-e. Obs.: Parâmetro opcional. bMostrarPreview - exibe o preview antes da impressão (1 - para exibir). Obs.: Parâmetro opcional. cMarcaDagua - Imprime parâmetro informado como MarcaDagua. Obs.: Parâmetro opcional. bViaConsumidor - Emitir via do Consumidor (1 - para emitir) Obs.: Parâmetro opcional. bSimplificado - Imprimir DANFe modelo Simplificado (1 - para emitir). Obs.: Parâmetro opcional. NFE.ImprimirDanfe("c:\35XXXXXXXXXXXXXXXX550010000000050000000058-nfe.xml", , , ,1) Acredito que com o comando acima você vai conseguir visualizar o DANFE na tela sem a necessidade de imprimir no papel ou gerar um PDF.

Bom dia Heto Andrade, Nos seus testes você usou o CNPJ e certificado do seu cliente ou o seu? Se você usou o CNPJ e certificado do seu cliente com certeza tem alguém enviado o evento de manifestação do destinatário. Agora se você utilizou o seu CNPJ e certificado ao executar o DistribuicaoDFePorChaveNFe, verifique se no XML baixo não conste o seu CNPJ no grupo <autXML>

Bom dia Rogério, Se você utiliza o ACBrMonitor para emitir o CT-e, segue a orientação do BigWings.

Não se deve confundir o CNPJ do intermediador da transação (YB02), com o CNPJ da instituição de pagamento (YA05). Porém, em algumas situações poderá ser o mesmo CNPJ. Por exemplo: caso o intermediador da transação seja o responsável por fazer o pagamento ao vendedor (emitente da NF-e), deve ser informado no campo CNPJ da instituição de pagamento o CNPJ do intermediador. Portanto, para efeitos do CNPJ da instituição de pagamento, deve ser informada a instituição/empresa que fez o repasse de pagamento para o vendedor/remetente. Em outras palavras, o CNPJ do adquirente, subadquirente, intermediador ou instituição similar que efetuou o pagamento ao vendedor. Texto extraído da Nota Técnica 2020/006 versão 1.20 (página 12).

Os Ajustes SINIEF 21/2020 e 22/2020 introduziram a exigência da identificação do intermediador da transação comercial na NF-e e NFC-e. Sendo assim, foram criados 4 campos na NF-e/NFC-e, sendo eles: indIntermed (B25c), infIntermed (YB01), CNPJ (YB02) e idCadIntTran (YB03). O campo Indicador de intermediador/marketplace (indIntermed) é uma “flag” utilizada para o emitente da NF-e/NFC-e declarar quando a operação/venda ocorreu em site/marketplace ou plataforma de terceiro. Quando declarado que a operação for intermediada (indIntermed=1) será necessário informar os campos do grupo infIntermed (YB01): CNPJ (YB02) e idCadIntTran (YB03). Caracteriza-se venda com intermediador (indIntermed=1), quando o vendedor/emitente da NF-e/NFC-e (CNPJ14) for diferente do CNPJ14 do site/marketplace ou plataforma que realizou a venda. Em algumas situações, a venda/operação pode ocorrer com mais de um marketplace/intermediador, por exemplo quando o “Vendedor A” anuncia no “Marketplace M1” e este anuncia no “Marketplace M2”. Nesse caso, na hipótese do “Marketplace M1” ter enviado a informação para o “Vendedor A”, na NF-e deve ser informado o CNPJ do “Marketplace M1”. Em resumo, independente da cadeia de plataformas envolvidas, deve-se informar o CNPJ do intermediador (campo YB02) de quem que enviou a informação da venda para o vendedor/emitente da NF-e/NFC-e. Texto extraído da Nota Técnica 2020/006 versão 1.20 (página 12). Exemplos para quem utiliza o componente ACBrNFe: 1. Venda presencial no Estabelecimento ou Fora dele. Ide.indPres := pcPresencial ou pcPresencialForaEstabelecimento; Ide.indIntermed := iiSemOperacao; 2. Venda não presencial, pela Internet ou Teleatendimento ou com entrega a domicílio ou outros sem Intermediador. Ide.indPres := pcInternet ou pcTeleatendimento ou pcEntregaDomicilio ou pcOutros; Ide.indIntermed := iiOperacaoSemIntermediador; 3. Venda não presencial, pela Internet ou Teleatendimento ou com entrega a domicílio ou outros com Intermediador. Ide.indPres := pcInternet ou pcTeleatendimento ou pcEntregaDomicilio ou pcOutros; Ide.indIntermed := iiOperacaoComIntermediador; (...) // CNPJ do Intermediador da Transação (agenciador, plataforma de delivery, marketplace e similar) de serviços e de negócios. infIntermed.CNPJ := '1234'; // Identificador cadastrado no intermediador. // Nome do usuário ou identificação do perfil do vendedor no site do intermediador (agenciador, plataforma de delivery, // marketplace e similar) de serviços e de negócios. infIntermed.idCadIntTran := 'Zezinho'; Exemplos para quem utiliza o ACBrMonitor ou ACBrLibNFe: 1. Venda presencial no Estabelecimento ou Fora dele. [ide] indPres=1 ou 5 indIntermed= 2. Venda não presencial, pela Internet ou Teleatendimento ou com entrega a domicílio ou outros sem Intermediador. [ide] indPres=2 ou 3 ou 4 ou 5 indIntermed=0 3. Venda não presencial, pela Internet ou Teleatendimento ou com entrega a domicílio ou outros com Intermediador. [ide] indPres=2 ou 3 ou 4 ou 5 indIntermed=1 (...) [infIntermed] ; CNPJ do Intermediador da Transação (agenciador, plataforma de delivery, marketplace e similar) de serviços e de negócios. CNPJ=1234 ; Identificador cadastrado no intermediador. ; Nome do usuário ou identificação do perfil do vendedor no site do intermediador (agenciador, plataforma de delivery, ; marketplace e similar) de serviços e de negócios. idCadIntTran=Zezinho

ATENÇÃO! Parada programada do Portal Nacional da NF-e no dia 28/03/2021 das 8h às 12h No dia 28/03/2021, a partir das 8 h, serão executados procedimentos de manutenção que requerem que o Portal Nacional da NF-e fique indisponível. A operação vai durar no máximo 4 (quatro) horas. Assinado por: Receita Federal do Brasil

Bom dia, Veja essa noticia: Segundo essa nova versão da NT não devemos mais gerar a tag <indIntermed> quando o indPres for igual a 1.

Bom dia a todos, Foi publicado a versão 1.20 da NT 2020/006 (16/03/2021) . O que mudou? Alteração em algumas regras de validação da SEFAZ e data de ativação tanto no ambiente de homologação quanto de produção. Veja como ficou as datas: Versão Descrição Homologação Produção 1.00 Criação de campos e Regras de Validação - seção 2 desta NT 01/02/2021 05/04/2021 1.10 Prazo de implantação desta NT v1.00 e v.1.10 para SV-AN, SP, MG e GO 01/03/2021 05/04/2021 1.10 Inclusão das regras YB01-10, YB01-20 e YB02-10 para modelo 65 01/03/2021 05/04/2021 1.10 Regra YA02-50 , observação 2 01/03/2021 05/04/2021 1.10 Regra B25c-10, observação 2 05/04/2021 01/09/2021 1.10 Regra Y08-90, observação a critério da UF 01/03/2021 05/04/2021 1.20 Regras YA02-60, YA06-10 e B25c-10, YA02a-10 e YA02a-20, inclusão do campo YA02a - xPag até 03/05/2021 01/09/2021 1.20 Regra YA02-50 foi eliminada até 03/05/2021 - Regra YA02-60 que é aplicada tanto para NF-e quanto para NFC-e: Verificar se o código do meio de pagamento (tag: tPag) existe na Tabela de códigos dos meios de pagamentos publicada no Portal Nacional da Nota Fiscal Eletrônica Observação 1: Regra válida a partir de 03/05/2021 (ou antes dependendo da SEFAZ-Autorizadora) para homologação e 01/09/2021 para produção Regra YA06-10 que é aplicada tanto para NF-e quanto para NFC-e: Verificar se o Código da bandeira de cartão de crédito e/ou débito (campo: tBand) existe na tabela de códigos das operadoras de cartão de crédito e/ou débito publicada no Portal Nacional da Nota Fiscal Eletrônica Observação 1: Regra válida a partir de 03/05/2021 (ou antes dependendo da SEFAZ-Autorizadora) para homologação e 01/09/2021 para produção Regra B25c-10 que é aplicada tanto para NF-e quanto para NFC-e: Se Informado indicativo de presença, tag: indPres, IGUAL a 2, 3, 4 ou 9 - Obrigatório o preenchimento do campo Indicativo do Intermediador (tag: indIntermed) Observação 1: Regra válida a partir de 03/05/2021 (ou antes dependendo da SEFAZ-Autorizadora) para homologação e 01/09/2021 para produção. Regra YA02a-10 que é aplicada tanto para NF-e quanto para NFC-e: Quando o código do meio de pagamento (tag: tPag) for preenchido com o código 99-outros, obrigatório o preenchimento da descrição do meio de pagamento (tag: xPag) Regra YA02a-20 que é aplicada tanto para NF-e quanto para NFC-e: Quando o código do meio de pagamento for diferente 99-outros (tag: tPag<>99), proibido o preenchimento da descrição do meio de pagamento (tag: xPag) Regra YA02-50 que é aplicada tanto para NF-e quanto para NFC-e: Esse regra foi eliminada das regras de validação da SEFAZ no que se refere as Informações de Pagamento. Inclusão da tag <xPag> (opcional) dentro do grupo <detPag> Grupo de Detalhamento do Pagamento para atender as regras YA02a-10 e YA02a-20. O componente vai ser atualizado assim que foi publicado os novos schemas para atender a nova tag (xPag). Sendo assim fiquem atentos as atualizações dos fontes ACBr. Como vai ter alteração nos schemas se faz necessário atualizar os schemas nas maquinas dos seus clientes assim que eles estiverem disponíveis.

Boa tarde emdri, Você poderia anexar o XML da NF-e que foi rejeitada?

Boa tarde Alexandre, A cidade do Rio de Janeiro se utiliza do provedor RJ que segue a versão 1 do layout da ABRASF. Nessa versão só temos o serviço de envio de lote no modo assíncrono, portanto você deve utilizar o botão [Enviar Lote RPS (Enviar)]

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