Painel de líderes

Olá Pessoal, Já se encontra no SVN a atualização dos fontes do componente ACBrCTe que visa a versão 4.00 do CT-e. Até o momento é possível realizar testes em ambiente de homologação para as seguintes UF: MG, MS, SP, AP, PE, RR, AC, AL, AM, BA, CE, DF, ES, GO, MA, PA, PB, PI, RJ, RN, RO, RS, SC, SE e TO Quem ainda não atualizou os seus fontes não perca tempo. Lembre-se de atualizar todos os fontes de todas as pastas, reinstale o ACBr com a opção de apagar arquivos antigos marcada e por fim recompile a sua aplicação. Ainda esta semana será disponibilizado uma nova versão do ACBrMonitor Plus e do ACBrLibCTe para aqueles que desenvolvem as suas aplicações em outras linguagens. Informação Importante: A tag CRT (Código do Regime Tributário) na versão 4.00 passa a ser obrigatória.

Agora com o nosso componente ACBrBoleto é possível emitir Boletos através da API para o banco Banco Bancoob (Sicoob) A atualização já está em nossos repositórios ! Obrigado a comunidade que está nos ajudando e especialmente para o Marcelo Santos e Delmar de Lima que colocaram a mão na massa e iniciaram a contribuição deste componente.

Boa tarde. Conferindo no Portal da Nota Fiscal Eletrônica, é possível observar que a Sefaz de São Paulo está com contingência agendada para o dia 30/04/2023 com previsão de inicio as 06:00 horas e término as 16:00 horas do mesmo dia. Durante este período, para transmitir notas em contingência, siga as instruções do tópico a seguir: Um agradecimento especial ao membro de nossa comunidade @Jonas_Farsoft pelo aviso.

Agora com o nosso componente ACBrBoleto é possível emitir Boletos através da nova API para o banco Banco Sicredi V2. Outra boa notícia que a API versão V2 funciona o boleto Híbrido (com QrCode) para pagamento PIX. Já existia uma API do Sicredi denominada ECOMM, mas foi lançada uma nova versão denominada V2. A atualização já está em nossos repositórios ! Obrigado a comunidade que estão nos ajudando e especialmente para o @DevSolucaoSistemas que iniciou a contribuição deste componente e ao apoio nossos consultores @Victor H. Gonzales - Panda e @Juliomar Marchetti para a conclusão desta API tão esperada pelos novos clientes Sicredi.

EXEMPLO DE CONFIGURAÇÃO DO COMPONENTE ACBR BOLETO Bancoob (Sicoob) //Campos para homologacao de acordo com dados fornecidos pelo banco -- Demais configurações como de costume nos outros bancos Versão API do Banco: -Para utilizar a versão nova V3, informar: FACBrBoleto.Configuracoes.WebService.VersaoDF := 'V3'; -Para utilizar a versão em produção V2: FACBrBoleto.Configuracoes.WebService.VersaoDF := ''; Utilizar ambiente Sandbox, de testes (Somente V3, sandbox da anterior foi descontinuada): -AcBrBoleto.Configuracoes.WebService.Ambiente := taHomologacao; -AcBrBoleto.Cedente.CedenteWS.ClientID :='9b5e603e428cc477a2841e2683c92d21' ; Para sandbox, so precisamos do ClientID e estar em homologação. (nao precisamos de certificados, keyuser, clientsecret), precisa dos scopos Utilizar ambiente Produção: -AcBrBoleto.Configuracoes.WebService.Ambiente := taProducao; -AcBrBoleto.Cedente.CedenteWS.ClientID := Client_Id gerado no portal developpers sicoob; -AcBrBoleto.Cedente.CedenteWS.ClientSecret := Client_Id gerado no portal developpers sicoob; -AcBrBoleto.Cedente.CedenteWS.KeyUser := ''; //Deixar em branco (Access token (Bearer) criado pela solucao ACBr); -AcBrBoleto.Configuracoes.WebService.ArquivoCRT := 'c:\ChavePublica.pem'; -AcBrBoleto.Configuracoes.WebService.ArquivoKEY := 'c:\ChavePrivada.key'; Para extrair do certificado CRT e KEY, segue o link do post: https://www.projetoacbr.com.br/forum/topic/73380-exportar-certificado-pem-crt-e-key/ Demais campos iguais: AcBrBoleto.Cedente.CedenteWS.IndicadorPix := True; //para boleto híbrido AcBrBoleto.Configuracoes.WebService.SSLCryptLib := cryOpenSSL; AcBrBoleto.Configuracoes.WebService.SSLHTTPLib := httpOpenSSL; AcBrBoleto.Configuracoes.WebService.SSLType := LT_TLSv1_2; AcBrBoleto.Configuracoes.WebService.TimeOut := 30000; AcBrBoleto.Configuracoes.WebService.UseCertificateHTTP := True; Scope para V3: ACBrBoleto1.Cedente.CedenteWS.Scope := boletos_inclusao boletos_consulta boletos_alteracao Scope para V2: ACBrBoleto1.Cedente.CedenteWS.Scope := 'cobranca_boletos_consultar '+ 'cobranca_boletos_incluir '+ 'cobranca_boletos_pagador '+ 'cobranca_boletos_segunda_via '+ 'cobranca_boletos_descontos '+ 'cobranca_boletos_abatimentos '+ 'cobranca_boletos_valor_nominal '+ 'cobranca_boletos_seu_numero '+ 'cobranca_boletos_especie_documento '+ 'cobranca_boletos_baixa '+ 'cobranca_boletos_rateio_credito '+ 'cobranca_pagadores '+ 'cobranca_boletos_negativacoes_incluir '+ 'cobranca_boletos_negativacoes_alterar '+ 'cobranca_boletos_negativacoes_baixar '+ 'cobranca_boletos_protestos_incluir '+ 'cobranca_boletos_protestos_alterar '+ 'cobranca_boletos_protestos_desistir '+ 'cobranca_boletos_solicitacao_movimentacao_incluir '+ 'cobranca_boletos_solicitacao_movimentacao_consultar '+ 'cobranca_boletos_solicitacao_movimentacao_download '+ 'cobranca_boletos_prorrogacoes_data_vencimento '+ 'cobranca_boletos_prorrogacoes_data_limite_pagamento '+ 'cobranca_boletos_encargos_multas '+ 'cobranca_boletos_encargos_juros_mora '+ 'cobranca_boletos_pix '+ 'cobranca_boletos_faixa_nn_disponiveis';

Olá pessoal, Noticia da SEFAZ: 24/04/2023 - Tabela de Alíquotas de FCP por UF: Atualizada tabela contendo as alíquotas por UF do Fundo de Combate à Pobreza (FCP). A nova tabela pode ser baixada do Portal Nacional de NF-e clicando aqui.

Alguém mais também tem a impressão de que a Secretaria da Fazenda / Receita Estadual estão nos "tirando pra bobo"? Questionamentos que encaminhei ao Plantão Virtual em 03 de abril: Bom dia! Dúvida com relação a 2 trechos da IN RE Nº 081/22: 29.5.1 - A EMISSÃO DO COMPROVANTE DE PAGAMENTO efetuado com cartões de débito, de crédito e de loja ("private label"), transferência de recursos, transações eletrônicas do sistema de pagamento instantâneo e demais instrumentos de pagamento eletrônico, em vendas realizadas de forma presencial, deve estar vinculada à NFC-e emitida na operação, MEDIANTE INTERLIGAÇÃO COM O PROGRAMA EMISSOR DO DOCUMENTO FISCAL, a partir de: .... 29.5.1.2 - Na hipótese de impressão do DANFE da NFC-e, DEVE SER UTILIZADO O MESMO EQUIPAMENTO PARA A IMPRESSÃO DO COMPROVANTE REFERIDO SUBITEM 29.5.1. A) O comprovante de pagamento é o “ticket” impresso pelo POS, correto? (estamos falando de empresa que utiliza POS) Como esse “ticket” vai ser impresso pelo mesmo equipamento que imprimir o DANFE da NFC-e? Quando tomamos conhecimento da referida IN, lá em 26/09/2022, o entendimento que tivemos - como outras pessoas também - é que os contribuintes passariam a ser obrigados ao uso do chamado “T.E.F.”, em virtude do motivo acima e também do seguinte trecho da IN: “...mediante INTERLIGAÇÃO com o programa emissor do documento fiscal...” A Receita Estadual tem informado que NÃO é necessário, nem obrigatório, o uso do T.E.F., que as informações podem ser digitadas. Dessa forma, o contribuinte pode continuar a utilizar as máquinas conhecidas como POS. Mas aí, NÃO vai estar se cumprindo esses 2 pontos da Legislação. A empresa que utilizar POS não estará cumprindo nenhum dos 2 pontos: 1º) O DANFE da NFCe não será impresso pelo mesmo equipamento utilizado para a impressão do comprovante de pagamento, pois o DANFE será impresso pela impressora de NFCe e o comprovante de pagamento pela “maquininha” do POS. 2º) Não haverá INTERLIGAÇÃO entre POS e o programa emissor do documento fiscal. INTERLIGAÇÃO só é possível com a utilização de T.E.F. Desconheço outra solução disponível no mercado. RESPOSTA, recebida em 04 de abril: O item da Normativa que determina que os documentos devem ser impressos no mesmo equipamento está em revisão. O mais provável é que esse item seja removido da legislação. A Normativa NÃO determina, em nenhum lugar, que haja interligação entre o sistema POS e o sistema emissor de NFC-e. Isso não é exigido pela normativa. O que a Normativa determina, isso sim, é que haja INTEGRAÇÃO entre o comprovante de pagamento e a nota fiscal. Trata-se de uma coisa diferente de interligação. Essa integração é feita através de um código de identificação da operação. Esse código deve ser gerado e informado nos 2 documentos. Se o sistema da empresa gerar um código de identificação da operação, e esse código for impresso no comprovante de pagamento e informado em campo específico da nota fiscal, então haverá integração e a Normativa estará atendida. A Normativa não determina nenhum método específico pelo qual isso deve ser feito. A empresa pode utilizar o método que achar mais conveniente. É perfeitamente possível, por exemplo, que o código seja gerado em um dos sistemas, e depois digitado no outro. MINHA réplica: A IN, de fato, não determina que haja interligação entre sistema POS e o sistema emissor de NFC-e. No entanto, está escrito no item 29.5.1: ...mediante INTERLIGAÇÃO com o programa emissor do documento fiscal... Então, pela leitura de Legislação: a emissão do comprovante de pagamento, deve ser vinculada à NFC-e emitida na operação, mediante INTERLIGAÇÃO com o programa emissor do documento fiscal. Se precisa ter INTERLIGAÇÃO, a empresa não pode usar POS. A única forma de INTERLIGAR seria com uso de TEF. Para mim, INTERLIGAÇÃO leva ao entendimento de que são "coisas" que funcionam em conjunto, "que ligam uma na outra" (com fio, bluetooth, Wifi...). Peço desculpas se estou enganado, mas a minha forma de ler o que está escrito me levou a entender dessa forma. RESPOSTA recebida em 04 de abril: A intenção da legislação não é criar obrigatoriedade de usar sistema TEF. Se as palavras usadas na IN estão dando essa impressão, então talvez as palavras tenham que ser trocadas. Essa questão será encaminhada para a equipe responsável pela Normativa. O essencial é que um código de identificação da operação seja gerado, e seja informado nos 2 documentos. Isso pode ser feito através de sistema TEF ou de outro sistema. E ainda: “A opção de emitir a nota fiscal, e depois utilizar equipamento POS, será possível se o fornecedor do sistema POS realizar uma pequena customização, e acrescentar um campo para DIGITAÇÃO do código da operação.”

@carlitomorais Boa tarde ! Conforme comentei ontem em uma postagem do sr. e depois comentei na postagem da comunidade marcando o sr. tem alguns recursos como o boleto híbrido (com qrcode) que não foi validado ainda. Os testes que os usuarios fizeram que o qrcode funcionou são com as contribuições anexadas no tópico. Sendo assim, como comentei no topico abaixo, foi a tarefa K-3540-1 para que seja analisada as contribuições pela equipe de boleto.

Usa lá o ACBrLib que é dll no lugar do Monitor. dai seu PHP vai depender da dll se for windows ou so se for linux e aproveita tudo o que tu fez

Estou começando agora. Já deu certo. Obrigado,

por arquivo CNAB e API..

Bom dia. A TK foi atribuída a sprint dessa semana

Boa tarde, gostaria de saber se existe a possibilidade de desenvolvimento da API de cobrança para Banco BANSIRUL Segue link da documentação da API; https://developers-openbanking.banrisul.com.br/pages/PORTAL_V1.6.6/docs/clientes-banrisul/api-cobranca-v1.1.0.html

Boa tarde. Segue como sugestão de alteração no fonte do ACBRCEP. Quando não acha o cep estava retornando erro de violação de acesso ao tentar acessar os objetos no Json. Foi implementando se retornou um valor de cep valido. Ao tentar ler o objeto cidade e estado estava causando o erro. Exemplo da pesquisa anterior: Cidade : MARILIA Logradouro: CARLOS VENDRAMINI Estado: SP. Vi na pesquisa do WebService do CepAberto que Cidade e Estado são campo obrigatório. Este logradouro pertence a Oriente. Segue fonte em anexo. Obrigado Anderson ACBrCEP.pas

Erro é característico de falta das dlls de dependência.. tanto windows quanto linux.. No windows se você abrir o .zip do ACBrLib na pasta dep, vai encontrar as dll de dependência, você precisa copiar elas junto ao ACBrLib na versão que estiver utilizando.. Se estiver usando ACBrLib x86, então as dlls de dependência devem ser x86 também No Linux, você precisa se certificar de que os .so's foram instaladas na máquina..

Obrigado Atualizei os fontes e reinstalei os arquivos, está funcionando corretamente. Pode encerrar.

ok...vamos aguardar entao..

Boa tarde Bruno, Segundo o arquivo ACBrNFSeXServicos.ini temos o seguinte: [2507507] ; Atualizado em 15/03/2023 Nome=Joao Pessoa UF=PB Provedor=SisPMJP Versao=2.02 Params=NaoGerarTag:ValorIss ; ProRecepcionar=https://sispmjp.joaopessoa.pb.gov.br:8443/sispmjp/NfseWSService HomRecepcionar=https://nfsehomolog.joaopessoa.pb.gov.br:8443/sispmjp/NfseWSService Favor verificar qual ou quais condições a tag ValorISS deve ser gerada.

Funcionou! Só vou precisar de uma explicação sobre a propriedade LerNossoNumeroCompleto como e por que usar.... Do resto tá beleza.

Boa tarde @Andergoncalves, Abrimos um registro para avaliar a sua contribuição. (TK-3859) Caso seja aprovada e implementada avisaremos aqui! Obrigado pela contribuição!

25/04/2023 Implantação Versão 4.00 e NT 2023.001 em Homologação Comunicamos que a versão 4.00 e a NT 2023.001 encontram-se implantadas no ambiente de Homologação de empresas da SEFAZ Virtual RS.

Pois é Vinícius... E este "pequeno detalhe" não está ao alcance do empresário nem do desenvolvedor de ERP Isso, a SEFAZ teria que ter "combinado antes" com REDE, CIELO, STONE, "VERO", etc... Só que, pelo visto, a SEFAZ não tem poder de obrigar eles a fazerem isso e aí a SEFAZ vem com essa lengalenga de: "desde que o POS tenho esse recurso" Poxa!!! Nenhum POS tem esse recurso!!! E não é a empresa que vai fazer as ADQUIRENTES implementarem isso, ligando para o fale conosco delas.

Boa tarde Flavio, É qual é o provedor contratado por essa cidade? Pois no arquivo ACBrNFSeXServicos.ini não consta o provedor, veja: [4105607] Nome=Cidade Gaucha UF=PR Provedor=

@flavioz_lopes Deve ser incluído ao arquivo ACBrNFSeXServicos.ini do ACBr, hoje caso consulte esse município lá não tem nenhum provedor associado mesmo. Deve verificar qual o provedor e quais as URL´s de Homologação e Produção, para assim a equipe do ACBr poder incluir o provedor para esta cidade e poderem emitir as notas via WebService. Pelo que pesquisei deve ser o provedor GovDigital, mas de qualquer forma vá atrás das informações para verificar quais os dados corretos.

Boa tarde @phulano. Por favor, pelo Log que disponibilizou, da a entender que você gera o XML a parte e depois o carrega no Monitor para fazer o envio, é isso mesmo? Se for este o caso, por favor, confira no arquivo que está gerando qual valor está passando para a tag xMun do grupo emitente. Passando o arquivo XML que disponibilizou em Sefaz-RS - NF-e Validador de Mensagens do Projeto NF-e, ele acusou o seguinte erro: Schema XML: 225 - Rejeicao: Falha no Schema XML da NFe The 'http://www.portalfiscal.inf.br/nfe:xMun' element is invalid - The value '' is invalid according to its datatype 'String' - The Pattern constraint failed. E se conferirmos no seu XML no grupo enderEmit, ficou vazia a informação:

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

Boa tarde. Este campo não consta no leiaute da versão simplificada 1.1 e nem da versão simplificada 1.0(ambas disponíveis para leitura aqui). O evento S-1010 é o evtTabRubrica. Se conferirmos tanto schema evtTabRubrica-v_S_01_00_00.xsd quanto no evtTabRubrica-v_s_01_01_00.xsd não existe mais este campo. Mais informações sobre o porque isso foi removido neste tópico: A versão 2.5 já não é mais aceita pelo WebService do e-Social a muito tempo. Você deve usar a versão simplificada 1.1

Ah claro, então eles querem uma alteração pra ontem que envolva o desenvolvimento de novas máquinas POS integradas e o pessoal que jogue fora as máquinas existentes.

Boa tarde Pessoal, fiz alguns questionamentos para SEFAZ e olhem as respostas: 1. Nos casos em que o comprovante for impresso no POS, como devo proceder o preenchimento dos dados da transação nas tags do xml da NFCe? R:O POS pode ser utilizado, desde que o sistema de POS receba as informações a serem preenchidas no comprovante de pagamento. Se não houver uma integração direta entre o sistema POS e o sistema emissor de NF-e, então essa transferência de dados pode ser feita através de tecnologia wi-fi ou bluetooth. O sistema POS deverá prever esse recurso. Recomendamos contatar o representante do sistema POS, para perguntar sobre esse recurso. 2. Se eu disponibilizar ao usuário campo para informar o número do NSU (código de autorização) gerado pelo autorizador e impresso no comprovante do POS e preencher a tag Caut do xml com esse código, estarei atendendo ao regulamento mesmo que a impressão do comprovante do POS e do DANFE NFC-e, ocorram em equipamentos distintos? R: A digitação do NSU no sistema POS não é indicada. A orientação é que o número seja informado ao sistema POS de forma automática, conforme mencionado no item anterior. 3. Somente o NSU é suficiente ou será obrigatório também o preenchimento do código do autorizador, código da bandeira e tipo de transação (Crédito, débito ou voucher)? R:O NSIU da operação é o único código que a normativa exige que seja informado no comprovante de pagamento. Esse código deve ser informado também no campo específico da nota fiscal (tag "cAut", no arquivo XML). 4. O lojista deve entregar ao consumidor ambos os documentos? R: Sim. Na verdade, a maioria dos comerciantes já entrega atualmente ao consumidor os 2 documentos. 5. Como existe um número grande de autorizadores no mercado e um número maior ainda de bandeiras e o número do NSU/código de autorização normalmente contém vários dígitos, existe uma possibilidade enorme de erro de digitação por partes dos usuários durante o processo de digitação. De quem será a responsabilidade caso as informações sejam inseridas de forma errada? R:O código de identificação da operação deve ser gerado de forma automática por um sistema, e transmitido de forma também automática para o outro sistema. Isso vai evitar a possibilidade de erro de digitação. 6. Nas transações PIX, normalmente não ocorrem a impressão de comprovantes, de modo que o consumidor apenas apresenta, no próprio smartphone, o comprovante em tela. Neste caso, basta gerar o código no próprio XML e imprimir no DANFE NFC-e? R: A normativa ainda não possui uma orientação clara a respeito deste caso. A orientação para esse caso deverá estar integrada à normativa nas próximas semanas. 7. Nas vendas de crediário em que o estabelecimento receberá o pagamento em momento posterior a emissão da NFC-e e é possível que o pagamento ocorra em espécie. Por não saber se o recebimento ocorrerá por meio eletrônico ou em espécie, seria correto já gerar um código de autorização controlado pelo sistema, como se estivéssemos tratando de pagamento eletrônico? R: Nesse caso, o código de identificação da operação deverá ser gerado e informado na NF-e. Esse número ficará registrado e poderá ser consultado pelo sistema da empresa posteriormente. Depois, quando for feito o pagamento, então o sistema da empresa poderá consultar a nota fiscal que está sendo paga, verificar qual é o código da operação correspondente, e informar o mesmo código no comprovante de pagamento. não ta claro as respostas

Bom dia, Utilizo o componente do ACBr para transacionar com a Shipay. Hoje ao fazer o update do componente, deu erro no método GetWallets. Fui procurar a alteração no fonte de exemplo, para ver para qual comando foi substituido ou para qual unit o mesmo poderia ter sido alterado, porém o exemplo também estava usando o metodo GetWallets e conseguentemente não compilando. Indo mais a fundo, analisando os fontes, percebi que o método em questão foi alterado de public para private. Fiz a alteração provisória aqui no fonte do ACBr para poder continuar a usar, visto que essa função é importante para que eu liste para o operador as opções disponíveis, para que ele possa selecionar a mais adequada (Chamo a função e renderizo os botões das opções na tela). Gostaria de saber se é possível manter essa função como public no fonte oficial ? Att,

Opa @EliasCesar, Fiz o update e depois o teste aqui e funcionou certinho, Muito obrigado.

Bom dia. Mude no seu cedente.ini de TipoPessoa para TipoInscricao. Considerando o ini que anexou, ficaria TipoInscricao=0. Após isso, faça um novo teste.

Bom dia @phulano O ACBrMonitorPLUS está na versão 1.4.0.167 e pelo seu print pude notar que está com uma versão desatualizada. Poderia baixar a versão mais nova e realizar a operação novamente?

Foi gerado o arquivo XML? É possível compartilhar para análise? Caso tenha dados sensíveis, siga as orientações deste tópico para disponibilizar:

Bom dia @Desenvolvimento Farol Soft, Foi registrada a TK-3856 para análise da documentação. Caso deseje iniciar a implementação e compartilhar o código conosco a contribuição será muito bem-vinda.

@Pedro A. Araújo, @William Mattos, @Junior.Jaru e @carlitomorais Sobre o tópico: "Problemas com boleto hibrido (boleto com Pix) Sicoob", o mesmo foi fechado para continuarmos aqui, para que possamos concentrar as contribuições em um único lugar apenas. Criado a tarefa K-3540-1 para que seja analisada as contribuições pela equipe de boleto.

@carlitomorais, @Pedro A. Araújo, @Junior.Jaru Boa tarde ! Para organizar estas contribuições, estas units que estão sendo anexadas como vi nos posts acima.. podemos deixar td concentrado em um único post/tópico no forum? Sendo assim vou fechar este e mantemos neste tópico abaixo: Pq vou abrir uma tarefa para análise e tem vários códigos compartilhados em ambos tópicos. Assim deixamos em apenas um local.

De fato meu caro, são muitas informações conflitantes. SmartPOS integrado com o ERP é muito complicado, o volume de transação, o custo de servidores entre outros fatores. Ai vem um monte de gente com lorota vendendo SmartPOS e no final nao integra com o ERP. Só coloca mais controle manual e retrabalho para o empresário. Outro ponto do vídeo com a AFRAC, o caso do pagamento em crediário: emitir a NFCe com cfop 5949, mas o 5949 nao autoriza na NFCe. Como outro colega disse: é tanto desencontro de informação que chega a ser descanso com o contribuinte e as software houses.

Bom dia a todos, Acredito que como existe um evento de prestação em desacordo emitido pelo tomador e este evento contem a chave do CT-e, a SEFAZ entende que os valores do CT-e foram anulados ao emitir o CT-e de Substituição. A minha duvida agora é com relação ao tomador que não é contribuinte e que emitia uma carta de próprio punho.

Boa tarde, Não. Você se refere a tributação de todos os tipos de impostos existentes? Nesse caso não há um recurso para tal. Agora... caso seja para atender a lei De Olho no Imposto, onde simula o valor aproximado dos tributos federais, estaduais e municipais, utilize o componente ACBrIBPTax

Segue anexo o fonte ACBrSedex, para ser analisado retorno das informações do rastreio ACBrSedex.pas

Olá pessoal, Como pode ser visto na postagem anterior, não tínhamos o dia exato de quando as mudanças entrariam em vigor, mas agora no Portal do CT-e da SEFAZ-Virtual do RS já temos a data completa, conforme listado abaixo. Homologação: em 24/04/2023 (junto com a versão 4.00) Produção: em 26/06/2023 (junto com a versão 4.00) At.

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, Quinta feira (30/03/2023) enviei para o SVN uma atualização dos fontes do ACBrCT-e visando atender a versão 4.00 do CT-e. Já esta tudo no SVN, os novos schemas bem como os fontes atualizados do componente. Por favor atualizem todos os fontes de todas as pastas, reinstale o ACBr e inicie os testes. Lembre-se que agora devemos configurar o componente para a versão 4.00, sendo assim devemos atribuir o valor ve400 a propriedade VersaoDF. Não sei se todas as UF já estão com os seus ambientes de homologação preparados para a versão 4.00, uma vez que nos manuais consta somente 04/2023, conforme postagem anterior. Mas não custa nada tentar. Qualquer problema, favor criar um tópico no fórum para que possamos fazer as devidas correções. Desde já muito obrigado pela colaboração nos testes.

Enviei ajuste para o SVN, rev. 28899, com as alterações para exibir o CST no DANFe em Fast e Fast Report. Por favor, faça cópia das tuas alterações em outro local, depois um revert nos teus fontes para desconsiderá-las, e depois atualize para obter as correções.

Boa trade, Dias atrás, antes do "avanço" no assunto, enviei 5 perguntas (algumas com adendos) através do NAVi (Núcleo de Atendimento Virtual) e vou deixar abaixo o retorno obtido hoje: Dúvida 1: Será possível manter o recebimento de clientes através de máquinas POS em vendas realizadas por NFC-e? Neste cenário, a empresa iria realizar o recebimento através de uma máquina POS e antes de transmitir a NFC-e à SEFAZ, digitaria manualmente no Software ERP o Número da Autorização de pagamento (gerado pela máquina POS). Este número seria salvo no Banco de Dados, anexado ao XML (tag cAut) e impresso junto ao comprovante de pagamento na NFC-e. Resposta: O POS pode ser utilizado, desde que o sistema de POS receba as informações a serem preenchidas no comprovante de pagamento. Se não houver uma integração direta entre o sistema POS e o sistema emissor de NF-e, então essa transferência de dados pode ser feita através de tecnologia wi-fi ou bluetooth. O sistema POS deverá prever esse recurso. Recomendamos contatar o representante do sistema POS, para perguntar sobre esse recurso. Dúvida 2: Para recebimentos via PIX que não passam por uma integração TEF, o Software ERP deverá gerar um Número de Autorização próprio? Em caso positivo, este Número de Autorização gerado pelo Software ERP, deverá ser transmitido no XML (tag cAut > específica para cartões) ou deverá apenas ficar registrada no Banco de Dados e ser impressa junto ao comprovante de pagamento na NFC-e? Resposta: Para recebimento no PIX, da mesma forma que com qualquer outro meio de pagamento eletrônico, deve ser gerado um código de identificação da operação. esse código deve ser impresso no comprovante de pagamento, e informado em campo específico da nota fiscal (tag "cAut", no arquivo XML). Dúvida 3: Tanto o DECRETO Nº 56.670 quanto a INSTRUÇÃO NORMATIVA RE Nº 108/22 não obrigam a empresa a ter uma Integração TEF para recebimento de Cartões/Transferências Eletrônicas como meio de pagamento vinculado à vendas registradas por NFC-e, correto? Resposta: A legislação não obriga a empresa a utilizar um sistema TEF. Pode ser usado qualquer sistema que forneça as informações solicitadas. Dúvida 4: Tanto o DECRETO Nº 56.670 quanto a INSTRUÇÃO NORMATIVA RE Nº 108/22 não impedem a empresa de receberem via máquinas POS (cartões) valores de vendas vinculadas à NFC-e, correto? Resposta: A empresa não é impedida de usar sistema POS, desde que o sistema POS forneça as informações solicitadas, conforme mencionado na questão Dúvida 5: Tanto o DECRETO Nº 56.670 quanto a INSTRUÇÃO NORMATIVA RE Nº 108/22 não impedem a empresa de inserir manualmente o Número de Autorização de pagamento gerado pela máquina POS dentro do Software ERP, desde que estas informações fiquem salvas e saiam no comprovante de pagamento, correto? Resposta: O Decreto Nº 56.670 utiliza a palavra "vinculação". Isso implica em transmissão automática de dados, ao invés de digitação manual. Aqui existem clientes com máquinas POS variadas e basicamente "adequar" cada cliente geraria um desgaste enorme e conforme citado acima, as máquinas POS nem oferecem tal recurso. Fora o fato de informar um número de autenticação em um grupo destinado para cartões (aparentemente este é o menor dos problemas aqui).

Meu sentimento é que eles não sabem bem como levar essa situação. Tenho alguns clientes muito pequenos que é inviável uma solução TEF... E um SmartPOS também não daria conta. A reinvindicação para um limite de exceção em cima de determinado faturamento seria fundamental em minha opinião.