Painel de líderes

Boa tarde Pessoal, Segundo o Manual da versão 4.00 do CT-e diz que o ambiente de homologação estaria disponível a partir de 04/2023, já estamos em abrir e nada do ambiente de homologação estar disponível para testes. A Equipe ACBr entrou em contato com a AFRAC (AFRAC - Associação Brasileira de Tecnologia para o Comércio e Serviços) uma vez que somos associados e obtivemos mais informações que não constam no manual. 1. a versão 3.00 do CT-e vai conviver com a versão 4.00 por 6 meses. 2. a SEFAZ em breve vai publicar as novas URL da versão 4.00 A SEFAZ não divulgou datas especificas, mas estamos todos os dias consultando o Portal Nacional do CT-e em busca de novidades. Assim que tivermos novidades, vamos dar continuidade a esta postagem e avisaremos também no Discord.

Boa tarde pessoal, Como podemos perceber pelo tamanho deste tópico, ainda existem muitas dúvidas sobre PIX, uso de POS e outras questões, e exatamente visando ir em busca de mais esclarecimentos, a AFRAC abriu a todos o formulário de captura das duvidas relacionadas ao tema, as quais serão abordadas pelo fisco em reunião entre os associados e os responsáveis da SEFAZ-RS https://forms.gle/Ha9PtRLFv3J7VWRi8

Os campos Instrução 1 e 2 são informações de operações que são enviadas junto do boleto. Podem ser relacionados a juros e multa mas não exclusivamente relacionados a isso. De acordo com o banco que está sendo usado para emitir existem códígos correspondentes e pode ser necessário preencher outros campos alem desses. Qual banco está utilizando?

Acabei de enviar uma nova pergunta para o plantão da sefaz, e vejam o retorno: "Boa tarde, Em primeiro lugar, precisamos ressaltar que o texto que foi enviado em anexo não é um parecer oficial. Esse texto é apenas uma comunicação informal em caráter extra-oficial. Isso está escrito no próprio texto. De qualquer forma, o que está escrito não está correto. A normativa determina que o código de identificação da operação seja identificado, e que ele deve ser gerado no comprovante de pagamento e também informado no campo próprio da nota fiscal. Porém, a Normativa não coloca nenhuma definição a respeito do método que deve ser usado. A empresa pode utilizar o método que achar mais conveniente. Em particular, não há nada na normativa que diga que a integração deva necessariamente ser feita por método automático. A integração pode ser feita de forma manual. É perfeitamente possível que uma empresa utilize sistema POS, e que o código da operação seja digitado manualmente, da mesma forma como o usuário digita atualmente o valor da operação. Não há nenhum impedimento na Normativa quanto a isso. No texto em anexo, está escrita a afirmação de que "não é possível a integração que não seja manual dos dados". E daí? Não há nada na Normativa que diga que a integração não possa ser manual." Os caras nao dizem nem que sim nem que não. Fica difícil. Em anexo o email na integra. RE ENC NFC-e - Nota Fiscal ao Consumidor Eletrônica PFV-233921-C6V3W.pdf

Olá pessoal, Lá vamos nós mais uma vez, só que agora é a vez de algumas melhorias no CT-e. E quais são as novidades da versão 4.00 do CT-e? Eliminação do SOAP Header dos Webservices Não precisamos se preocupar pois o componente vai se encarregar de não gerar o grupo <Header> ao montar o Envelope a ser enviado para o WebService da SEFAZ. Eliminação da Denegação e do CTe de Anulação Com essa nova versão não teremos mais como emitir um CT-e de Anulação, somente CT-e Normal, CT-e Complementar e CT-e de Substituição. O Manual não diz o porque, mas acredito que essa alteração vem de encontro com o DC-e (Declaração de Conteúdo Eletrônico). Quanto a Denegação o que tudo indica nenhum CT-e vai ser Denegado, ou seja, ou ele vai ser autorizado ou rejeitado. Eliminação do Serviço de Autorização Assíncrono O envio do CT-e passa a ser no modo síncrono e unitário, ou seja, somente um CT-e por vez será enviado para o WebService e já teremos como resposta o protocolo de autorização ou a rejeição. Ampliação do Nro Seq dos Eventos Antes um tipo de evento que poderia ser enviado mais de uma vez (por exemplo Carta de Correção) estava limitado a 20, agora o limite é 999. Eliminação do serviço de inutilização Com a versão 4.00 não teremos mais como inutilizar um numero de um CT-e que não foi enviado para a SEFAZ, acredito que caso ocorra um pulo, por exemplo, foi enviado o CT-e de numero 500 e por algum problema foi enviado o CT-e de numero 505, vai ser possível em seguida enviar os CT-e de números 501, 502, 503 e 504 para depois voltar a sequencia normal ou seja emitir o CT-e de numero 506 em diante. Sobre os prazos A versão 4.00 vai estar disponível a partir de 04/2023 em ambiente de Homologação e a partir de 06/2023 em Produção. Quanto as Soluções ACBr Haverão ajustes no componente ACBrCTe para atender a versão 4.00, oque naturalmente se refletirá nas versões posteriores da ACBrLibCTe e do ACBrMonitor. Fiquem atentos as atualizações dos fontes do ACBr e não percam o bonde. Quanto a minha Aplicação? Com certeza a sua aplicação deve ter uma opção para emitir CT-e de Anulação e Inutilização de Números, pois bem essas opção não poderão mais poder ser utilizadas com a nova versão. Sugerimos que apresente uma mensagem ao usuário informando que essa opção não esta mais disponível na versão 4.00 do CT-e. Se a sua aplicação permitia o envio de um lote de CT-e, agora só será possível enviar um de cada vez, logo você vai ter que mudar isso. Com certeza a sua aplicação envia eventos, fique atento a esta questão: para os tipos de eventos que permite enviar mais do que 1 para o mesmo CT-e, lembre-se que agora o limite passou de 20 para 999. Leitura recomendada: Temos os manuais (que são 3) da versão 4.00 em nossas biblioteca. http://svn.code.sf.net/p/acbr/code/tools/DFe/CTe/

Boa tarde. Foi divulgado no dia 24/03/2023 a NT2023/001 tratando de alterações de regras de validação para CTe, CTeOS e GTVe. Resumo da Nota Técnica: Esta Nota Técnica promove ajustes nas regras de validação do CTe, CTeOS e GTVe visando adequar o sistema à legislação aprovada no AJUSTE SINIEF. Data para Implantação: Implantação Homologação: 04/2023 Implantação Produção: 06/2023 Sobre as alterações: Eliminação da Denegação Interestadual As hipóteses da Denegação no processo de autorização dos documentos deixam de existir. A validação do CTe poderá resultar em: Rejeição – o CTe será descartado, não sendo armazenada no Banco de Dados podendo ser corrigido e novamente transmitido; Autorização de uso – o CTe será armazenado no Banco de Dados; Regras de Validação de CTe, CTeOS e GTVe No geral, a redação da NT remove das regras G036, G068, G074, G096 e N064 a palavra denegado. Além disso, adiciona a seguinte observação na regra G110: E também remove as regras abaixo: Regras de Validação G133, N089 e Q026: cStat - 301/ cStat - 205. Emitente em situação irregular perante o Fisco (tratar duplicidade na inserção do CT-e, evitando a inserção de mais de um CT-e denegado). Uso Denegado: Irregularidade fiscal do emitente. Regra de Validação G183 e N106: cStat - 205. - Verificar se CT-e está denegado Retornar Protocolo e data de denegação. [nProt:999999999999999][dhDeneg: AAAA-MMDDTHH:MM:SS TZD]. Rejeição: CT-e está denegado na base de dados da SEFAZ. Eliminar o Serviço de Inutilização O Webservice de Inutilização deixa de existir nas datas de implantação desta NT conforme o ambiente. O acesso ao Serviço será bloqueado pela SEFAZ Autorizadora, podendo retornar um erro http 404 (Not found) ou a rejeição 998 – Serviço Desativado. Revogação dos Eventos de Marcação Os seguintes eventos de marcação deixam de ser gerados pelas SEFAZ Autorizadoras: 440130| 57| Autorizado Redespacho 440140| 57| Autorizado Redespacho intermediário 440150| 57| Autorizado Subcontratação 240150| 57 e 67| CTe de Anulação CTe de Anulação e Substituição na Versão 3.00 O CTe com tipo anulação e substituição deixam de existir na versão 3.00. A nova sistemática de substituição passa a ser possível apenas na versão 4.00. As seguintes Regras de Validação devem ser executadas no início das validações de CTe, CTeOS e GTVe: Se Tipo do CT-e= 2 (Anulação) ou 3 (Substituição), rejeitar o CTe cStat - 990: Rej. Rejeição: Vedado a utilização do CTe de anulação ou substituição na versão 3.00 O grupo de dado do CTe de substituição não pode ser informado (grupo: infCteSub) cStat - 991: Rej. Rejeição: Dados do CTe de substituição não são permitidos na versão 3.00 Todas as regras de validação associadas aos CTe de anulação e substituição perdem o sentido porque o ambiente de autorização não passará por elas. Revogação do Evento de Informações da GTV no CTeOS e suas implicações Revoga-se o evento de Informações da GTV (em papel) no CTeOS de Transporte de valores para as versões 3.00 e 4.00. Tipo de evento revogado: 110170. Em relação as Regras de Validação do CTeOS as seguintes alterações serão aplicadas a versão 3.00 (até sua total desativação) e na versão 4.00: Regra de Validação Revogada Se tipo de serviço = Transporte de Valores - Verificar se existe CTe OS autorizado há mais de 45 dias para o mesmo CNPJ do emitente sem que exista pelo menos um evento de Informações da GTV vinculado Observação: Retornar a chave de acesso do CTe OS mais antigo que causou o bloqueio Observação 2: Essa validação não deve ser aplicada no ambiente de homologação. Observação 3: A validação não deve ser aplicada a CTe OS de transporte de valores que relacionam GTVe. Rejeição: Existe CTe OS de Transporte de Valores autorizado há mais de 45 dias sem informar as GTV [chCTe: 99999999999999999999999999999999999999999 999]. Nova Regra de Validação para Transporte de Valores H045a: cStat - 927. Se tipo de serviço for igual a Transporte de Valores - O grupo de informações infGTVe DEVE estar informado. Rejeição: Informações da GTVe devem ser preenchidas para CTe OS de transporte de valores. Retificação de informação do MOC 4.00 O valor de preenchimento da tag CST do grupo ICMSSN deve ser conforme está no schema da versão 4.00 com o valor 90 – Simples Nacional e não 01 – Simples Nacional como saiu no MOC. A tag correta deverá aceitar apenas o valor 90 – Simples Nacional. Modificações no ACBr. De maneira bem resumida, a Nota Técnica discorre sobre algumas regras de validação e o fim do evento de inutilização. Por isso, modificações no ACBr não se fazem necessárias. Dito isso será preciso que validem em suas aplicações para remover a possibilidade de enviar este evento. Esta e outras Notas Técnicas disponíveis AQUI. Você pode ler esta Nota Técnica na íntegra AQUI.

Bom dia Para atender a legislação de pagamentos com Transferência eletrônica de Fundos no Rio Grande do Sul, se torna necessário o preenchimento da tag cAut para formas de pagamento que não sejam com cartão de crédito ou débito. Para pagamentos com a forma 05-Crédito Loja, será necessário preencher essa tag cAut com um código de autorização aleatório. Caso o pagamento dessa nfce seja feito futuramente com cartão de crédito ou débito, esse código aleatório deverá ser impresso no comprovante da transação TEF. Como sugestão, para ficar bem flexível, não deveria se condicionar a tag cAut a uma ou outra forma de pagamento. Fica a critério do sistema, preencher a tag quando necessário, independente da forma de pagamento utilizada e, sempre que a tag for preenchida, gerar a mesma no xml e imprimir junto a forma de pagamento da Danfe.

Diego muito Obrigado,... vou estudar,...

Boa tarde pessoal Recebemos a informação de que a entrada em homologação será em 24/04/2023 e em Produção em 26/06/2023 At.

Boa tarde Willian, Vamos a mensagem de erro: X800 - Erro de Validação: --> 1871 - Element '{http://www.abrasf.org.br/nfse.xsd}OutrasInformacoes': This element is not expected. - 1. o erro X800 ocorre quando o componente confronta o XML com o XSD e detecta uma anomalia, neste o processo de envio é abortado. 2. a mensagem diz que o elemento OutrasInformacoes não é esperado, isso significa que o componente gerou a tag OutrasInformacoes e ao confrontar o XML com o XSD ele não encontrou essa tag no XSD na posição que a mesma foi gerada no XML. 3. é preciso verificar se o XSD que o componente esta pegando para fazer essa validação contem a tag ou não. 4. caso afirmativo alterar na unit Provider, na procedure Configuracoes para que a validação não ocorra, assim o XML vai ser gerado e vamos poder chegar se a tag esta sendo gerada na posição esperada. Ficaremos gratos se você conseguir fazer essas verificações.

Boa tarde Almeida, Segundo o Schema que temos esse tipo de consulta não requer assinatura, veja: <xsd:element name="ConsultarNfseRpsEnvio"> <xsd:complexType> <xsd:sequence> <xsd:element name="IdentificacaoRps" type="tcIdentificacaoRps" minOccurs="1" maxOccurs="1" /> <xsd:element name="Prestador" type="tcIdentificacaoPrestador" minOccurs="1" maxOccurs="1" /> </xsd:sequence> </xsd:complexType> </xsd:element> Entre em contato com o provedor e expõe o problema. Pode ser um erro no webservice ou os schemas que temos deste provedor requer uma atualização, neste caso seria importante o provedor fornecer o schema correto.

entendi... acho que irá resolver sim.. irei ajustar.. obrigado

Boa tarde @willian_delan. Por favor, qual é a cidade que está emitindo? Além dos fontes você também atualizou o schema nesse cliente e o problema persistiu?

Boa tarde, Na aba WebService qual é o valor de SSLType? Outra coisa, se o certificado esta instalado na maquina não é necessário informar a senha, somente o seu numero de série.

Boa tarde, Rubinho Na verdade fiquei sem solução, não sei porque em ambiente homologação, só consigo testar nota com um cnpj os outros retornam com erro, mais o suporte não respondeu mais nada, em ambiente produção esta funcionando normal

Informe se está utilizando a lib, monitor ou o componente. Como está passando as informações? No programa de exemplo acontece o mesmo?

Boa tarde, Pode informar qual foi a solução para que seja útil a quem tiver o mesmo problema futuramente? Bastou informar o tomador?

Não

Bom dia, Falando a nível de venda / cancelamento. para amenizar, não resolver o caso : - Você pode salvar o número da sessão, seja da venda ou do cancelamento, e se na resposta voltar insucesso enviar a consulta da sessão informando esse dados. Lembrando que se enviar alguma informação irá invalidar a sessão, então usar com parcimônia

@Wagner J.'. Rocha Este método indicado pelo fabricante é novo... e pode não existir em SATs como layout 0 07 Ele já foi implementado no nosso componente em Delphi há algum tempo... Mas ainda não havia sido mapeado no ACBrMonitor ou ACBrLibSAT Creio que não seja um desenvolvimento demorado... e provavelmente na próxima compilação já teremos o método mapeado

Como acompanho o andamento deste #TK-3824 ?

Por favor, verifique se o processo de envio chega a ocorrer ou se ele falha na validação, caso esteja falhando na validação antes mesmo de enviar, peço que revise novamente sua configuração de schemas e de SSLib. Eu não tenho dados válidos de uma prestador, mas obtive o seguinte resultado ao testar com o programa exemplo:

Criada a #TK-3824 para tratar sobre o assunto.

Opa boa tarde Obrigado pelo retorno, porem aqui na empresa veio um contator e me mostrou como funciona os calculos, e fiz um curso por fora, ja foi implantado. Obrigado. Opa boa tarde Obrigado pelo retorno, porem aqui na empresa veio um contator e me mostrou como funciona os calculos, e fiz um curso por fora, ja foi implantado. Obrigado.

https://www.google.com/search?q=delphi+enumeration+type+to+combobox&oq=delphi+enumeration+type+to+combobox&aqs=edge..69i57j0i546l3j69i64.9976j0j1&sourceid=chrome&ie=UTF-8 https://stackoverflow.com/questions/44906561/populate-combobox-with-enum-in-delphi-with-mysql

Tenha certeza de utilizar a: DistribuicaoDFePorUltNSU e não a: DistribuicaoDFePorNSU Outra coisa, se não tiver feito ainda, tente passar zero como ultNSU para baixar novamente tudo disponível no período.

Uso ACBrNFSeX, está emitindo normal

É um comportamento estranho do webservice, ele devia retornar os 50 primeiros documentos dos últimos 90 dias, mas retornou <ultNSU informado> + 50, e provavelmente esses NSU antigos já tem mais de 90 dias portanto não retorna nada. Não vejo o que fazer a não ser aguardar 1h (pra não ter consumo indevido) e consultar novamente, vai consultando de 50 em 50 até chegar nos NSU atuais.

Boa tarde a todos. Era problema no ambiente da prefeitura, o qual já foi resolvido. Conseguimos voltar a emitir normalmente. Obs.: Não usamos o componente ACBrNFSe.

Será que o problema não está no ultNSU informado na requisição (50)? Muito antigo? Para ver se é gerado algum retorno de documentos, poderia tentar informando um NSU que provavelmente é mais recente, por exemplo 6700 (já que 6723 seria o maxNSU disponível).

Informações Extraoficiais sobre os pontos ainda Nebulosos Como muitos vem acompanhando, as questões envolvendo PIX externo ao TEF, uso de POS, operações de pagamento com meios eletrônicos relacionas a pagamento de compras feitas com parcelamento em carne, tem gerado muitas interrogações dentro das SHs. Estive hoje em contato com a AFRAC e até o momento temos as seguintes informações em caráter extraoficial Ainda não há definição de como deve ser informado o PIX feito externo ao TEF, por isso o desencontro de informações vindas pelo Fale Conosco O uso de POS como recebimento das vendas, não está autorizado já que não é possível a integração que não seja inserção manual dos dados Diante deste cenário de pontos a esclarecer, a fiscalização será orientativa Existe a possibilidade que a obrigatoriedade prevista para 01/07 seja postergada. Ainda no mês de abril deve acontecer uma reunião entre o Fisco do RS e os associados da AFRAC, onde o fisco deve voltar a falar sobre as dúvidas que tem recebido. Sendo assim, convidamos a comunidade a continuar a enviar suas dúvidas no tópico a seguir.

É bem estranho que isso esteja acontecendo, quando comecei a ler suspeitei que o teu IP estivesse bloqueado, mas se está acontecendo com outros clientes então não deve ser isso. O DistribuicaoDFe é hospedado no ambiente nacional, então não faz diferença de qual estado está consultando. Eu testei agora com os meus e não tive problemas também. Qual é a mensagem de retorno da rejeição?

Geralmente quando dá isto é por que há algum outro programa fazendo as pesquisas das notas como FSist seja na máquina do cliente ou no contador. Não aconteceu com nenhum dos meus clientes recentemente isto e toda que vez que aconteceu era esta a situação. Se persistir, abra um chamado na Sefaz para entender com eles.

Boa tarde pessoal ! Recebemos uma comunicação da ELGIN nesta tarde e estamos repassando: Caro parceiro, desenvolvedores e revendedores, Gostaríamos de informar que o SAT Linker II, o modelo mais antigo de nossa linha de produtos, recebeu uma atualização do SEFAZ nesta semana. É importante destacar que esta atualização já havia sido comunicada pelo SEFAZ semanas antes, através de uma mensagem direta para o SAT, que pode ser capturada pelo aplicativo de automação e exibida na loja. Visando respeitar nossos clientes e parceiros, gostaríamos de explicar o ocorrido e destacar os benefícios dessa atualização. É importante ressaltar que o SAT Linker II é um produto de 2015-2016, com mais de 8 anos de uso, e já não poderia ser atualizado devido à sua defasagem tecnológica, o que resultaria na necessidade de adquirir um novo equipamento. No entanto, fizemos um trabalho de engenharia para encontrar um caminho para atualizar o sistema do SAT Linker II, proporcionando uma vida útil mais longa ao equipamento e evitando a necessidade imediata de adquirir um novo modelo. Esta atualização também trouxe maior velocidade de operação ao dispositivo e a capacidade de operar com Layout 8.0, algo impensável para um SAT desse tempo de fabricação. Investimos horas de engenharia e homologação do equipamento, e após ser aprovado e testado, enviamos o comunicado ao SEFAZ, que resultou em aviso prévio e atualização instantânea. Embora um projeto como esse traga efeitos colaterais, eles não impedem a operação do equipamento. Aqui estão os esclarecimentos sobre cada um deles: Após a atualização do SEFAZ, todos os LEDs do Linker II permanecem piscando. É necessário desconectar todos os cabos do equipamento e aguardar até que os LEDs se apaguem em definitivo. Após isso, o aparelho deve ser religado e conectado em uma rede de internet para a atualização das Chaves do Certificado Digital. Esse processo é automático e não requer intervenção humana. Após isso, seu SAT Linker II está pronto para operar com os novos layouts e sistema interno mais moderno. Todo o processo acima resulta em dois efeitos: 2.1) O Contador de CFE (XXXXXXX) retornará para 000000001, como previsto na documentação técnica do SAT. Este sistema novo do Linker II foi testado, certificado, homologado e aprovado por órgãos competentes para operar assim. A duplicidade dos números não acarreta problemas fiscais, já que esses números foram usados há anos atrás. 2.2) Somente nos casos em que o Linker II opera com IP FIXO, esta atualização retorna o SAT para operar com IP dinâmico. Isso ocorre porque a atualização zera totalmente as configurações do equipamento, já que é um sistema operacional totalmente novo e mais moderno. Todas as configurações de rede serão zeradas e devem ser reconfiguradas. No entanto, isso se aplica apenas ao SAT LINKER II configurado explicitamente para trabalhar com IP FIXO. 2.3) Aconselhamos fortemente que, aproveitando-se desse momento de atualização do parque Link Windows https://github.com/ElginDeveloperCommunity/SAT/tree/master/Elgin/SMART%20SAT/Bibliotecas%20Windows Linux https://github.com/ElginDeveloperCommunity/SAT/tree/master/Elgin/SMART%20SAT/Bibliotecas%20Linux Android https://github.com/ElginDeveloperCommunity/SAT/tree/master/Elgin/SMART%20SAT/Biblioteca%20Android Para finalizar, comunicamos que a atualização do SEFAZ foi interrompida, em breve ela voltará a acontecer, por isso qq dúvida não hesite em nos acionar. Pedimos que considere este ocorrido com nossa ação para preservar seu investimento em um hardware (SAT Elgin Linker II) com 08 anos de operação trazendo uma sobrevida a ele. Claudenir Andrade

Resposta curta: Use o método ACBrTEFD1.CNC Ok, vamos explicar um pouco mais... O ACBrTEFD, tem um método exclusivo para Cancelamento, ACBrTEFD1.CNC, com ele o ACBrTEFD já iniciará uma transação administrativa, com informações suficientes, para localizar a transação no Banco de Dados do Gerenciador TEF, e iniciar o Cancelamento da mesma... Function CNC(const Rede, NSU : String; const DataHoraTransacao : TDateTime; const Valor : Double; CodigoAutorizacaoTransacao: String = '') : Boolean ; Veja abaixo, um exemplo de como você pode chamar o método: ACBrTEFD1.CNC( AResp.Rede, // PWINFO_AUTHSYST AResp.NSU, // PWINFO_AUTEXTREF AResp.DataHoraTransacaoLocal, // PWINFO_DATETIME AResp.ValorTotal, // PWINFO_TOTAMNT AResp.CodigoAutorizacaoTransacao); // PWINFO_AUTHCODE Lembramos entretanto, que cada adquirente, tem um fluxo de Cancelamento de transações, então pode ser que em alguns casos, outras informações sejam solicitadas, pelo Gerenciador TEF, por isso é sempre recomendado, ter o Cupom da Transação original, em mãos... Outro fato, é que sempre será solicitado o cartão do cliente, no final do processo... Ou seja, o Cliente precisa estar presente, para que o cancelamento seja efetuado...

Boa tarde pessoal, Estive em contato hj com a AFRAC e as questões envolvendo PIX, POS sem integração com a aplicação ainda estão nebulosos, e diante deste cenário ainda em abril o haverá uma reunião entre o Fisco e os associados da AFRAC para mitigar estes pontos. O FISCO do RS esta ciente que neste momento a implementação das informações do PIX não esta viabilizada, exceto quando passa pelo TEF, mas a questão do uso de POS para o processo de vendas, foi informado que não é permitido. Continuem enviado suas dúvida neste tópico para que possamos direcionar a AFRAC.

bom dia! alguma novidade sobre o decreto?