Italo Giurizzato Junior

Bom dia Eloildo, Muito obrigado pela colaboração, já inclui na minha lista de tarefas.

Bom dia, Não sei de qual website você se refere, mas esse arquivo esta desatualizado. Porque não instala o Tortoise e use ele para baixar os fontes do ACBr?

Bom dia Gutierres, Favor atualizar os fontes, pois não existe mais a pasta de schemas: SmarAPDv2. Se não me falha a memória fiz uma correção nos schemas desse provedor.

Bom dia Eduardo, A montagem do arquivo *-soap.xml esta totalmente diferente do especificado no arquivo INI do provedor. Você alterou o arquivo INI do provedor?

Bom dia Rauber, Se o webservice não gera o XML da NFS-e como deve ser, ou seja, como consta no manual da ABRASF, o que nos resta fazer? Ler o que consta no XML e imprimir no DANFSE, pois seguimos a regra: se esta no XML imprimi, se não esta não imprimi.

Olá Pessoal, Enviei hoje dia 26/04/2021 as alterações no componente ACBrNFe para atender a NT 2020/006 versão 1.20, mais precisamente a tag xPag. Quero reforçar que essa nova tag só vai ser aceita no ambiente de homologação até o dia 03/05/2021. Em uma live que participei com desenvolvedores e SEFAZ, obtive a informação de um membro da SEFAZ que a tag xPag também é para ser liberada no ambiente de produção até o dia 03/05/2021. Mas as regras de validação descritas na referida NT só vão ser ativadas no ambiente de produção no dia 01/09/2021.

Bom dia Galegobr, Já se encontra no repositório a sua contribuição.

Boa tarde, Vou verificar se é necessário fazer mais alguma alteração.

Boa tarde Brajan, Se tratando de NFS-e o cenário é o seguinte: 1. Se você vai emitir a nota via site se faz necessário apenas possuir um usuário e senha. 2. Se você vai emitir a nota via webservice vai depender do que esta no arquivo INI do provedor, veja esses exemplos: Provedor Ginfes: [Assinar] RPS=0 Lote=1 URI=1 ConsSit=1 ConsLote=1 ConsNFSeRps=1 ConsNFSe=1 Cancelar=1 RpsGerar=0 LoteGerar=0 Substituir=0 Note que alguns campos o valor é UM, isso significa que se faz necessário a presença da assinatura digital, consequentemente o emitente tem que ter o certificado digital. Por exemplo para Cancelar uma nota, o pedido de cancelamento deve estar assinado. Provedor RLZ: [Assinar] RPS=0 Lote=0 URI=0 ConsSit=0 ConsLote=0 ConsNFSeRps=0 ConsNFSe=0 Cancelar=0 RpsGerar=0 LoteGerar=0 Substituir=0 Para o provedor RLZ, nada precisa ser assinado, logo o emitente não precisa ter um certificado digital. O caminho das pedras: O seu cliente é da cidade ABC, você procura a por essa cidade no arquivo Cidades.ini, nesse arquivo diz que o provedor é ABC, o passo seguinte é abrir o arquivo INI do provedor ABC, por fim procure pela sessão [Assinar], se algum campo tiver o valor UM, o seu cliente vai ter que ter um certificado digital. Simples assim.

Bom dia Sérgio, Não devemos alterar a unit pcnLeitor pois esta é utilizada por todos os componentes que emitem Documentos Fiscais Eletrônicos. Peço mais uma vez, anexe o XML de retorno que contem a data fora do padrão para que a equipe ACBr possa analisar e com isso decidir se há necessidade de alterar algo no pcnLeitor ou não. Evite ao máximo misturar assuntos em uma mesma postagem. Respondendo a sua ultima postagem que não tem nada haver com o assunto que esta sendo tratado, a resposta é: toda vez que você ADD os dados de um RPS na lista NotaFiscais o valor de Count é incrementado automaticamente. Se você envia um Rps por vez, e o Count esta sendo incrementado, isso significa que você não esta limpando a lista antes de ADD o novo Rps.

Bom dia Renato, Já enviei para o repositório a sua contribuição, muito obrigado.

Bom dia Destak, Foi feito uma alteração no arquivo INI do provedor, favor atualizar os fontes e fazer novos testes. Aguardo retorno.

Bom dia Paulo, Desculpe pela demora. Por favor atualize os fontes e faça novos testes, note que fiz alteração no arquivo INI do provedor e no arquivo Cidades.ini

Bom dia Maurício, Enviei uma possível correção para o provedor TechInfo. Favor atualizar os fontes e faça novos testes, note que fiz uma alteração no arquivo INI do provedor.

Boa tarde Robson, O que vem a ser atualizado para o seu cliente? Se ele se refere a troca do protocolo de autorização pelo de cancelamento, lhe pergunto. Em qual Manual ou Nota Técnica ou Ajuste SINIEF que diz que ao cancelar uma NF-e devemos realizar essa troca? Pois bem isso não esta escrito em lugar nenhum. Nos primórdios da NF-e o componente até fazia isso pois não existia um documento com validade jurídica que comprovasse o cancelamento. Mas hoje temos e é o evento de cancelamento. Para que um XML (arquivo de computador) tenha validade jurídica perante ao Fisco, ele deve estar assinado digitalmente e com o protocolo retornado pela SEFAZ-Autorizadora que atesta que ela processou com sucesso o documento enviado. Esse protocolo se tratando da NF-e é o protocolo de autorização, logo para o XML da NF-e ter validade jurídica ele precisa estar assinado e com o protocolo de autorização. Ao solicitar o cancelamento de uma NF-e, no final de todo o processo temos um outro documento que é salvo em disco com o nome de: *-procEventoNFe.xml Esse arquivo ele tem validade jurídica pois esta assinado digitalmente e contem o protocolo retornado da SEFAZ que atesta que o evento foi processado com sucesso e foi vinculado a NF-e. Temos então 2 XML: *-nfe.xml (XML da NF-e que deve estar assinado e com o protocolo de autorização) *-procEventoNFe.xml (XML do evento que deve estar assinado e com o protocolo que atesta o vinculo do mesmo a nota). Lembrando que existem diversos tipos de eventos e todos tem o mesmo nome o que muda é ID que compõe o nome que no caso do evento é formado pelo código do evento (6 dígitos) mais a chave da nota (44 dígitos) e o numero sequencial do evento (2 dígitos). Os XML referente aos eventos são salvos separadamente em outras pastas. Quem na verdade esta reclamando não é o seu cliente e sim o contador dele que deve utilizar um programa de escrita fiscal/contábil de mil novecentos e bolinha.

Bom dia Marcio, Nós procuramos seguir o que esta escrito nos manuais de impressão de Documentos Auxiliares, no caso do DANFE temos o Manual: MOC versão 7.01 -Anexo III Manual DANFE que esta disponível em nossa biblioteca (http://svn.code.sf.net/p/acbr/code/tools/DFe/NFeNFCe/Manuais/). Na página 16 temos o item 3.7: 3.7. Padrões de Caracteres (Tipos de Fontes) Todos os caracteres deverão estar impressos na fonte Times New Roman ou na fonte Courier New. A impressão dos dados variáveis feitas por Impressoras de Impacto (Matricial e de Linha) deverá estar entre 10 e 17 CPP (Caracteres por Polegada).

Bom dia Társis, Porque você esta usando o ACBrLibNFe, não esta mais usando o Delphi para desenvolver as suas aplicações? Lembre-se que o ACBrLib é para quem não trabalha com o Delphi ou Lazarus.

COORDENAÇÃO TÉCNICA DO ENCAT 19/04/2021 MDF-e e NFF Lançam Inovador Conceito de ICMS Pré-pago O Conceito de pré-pagamento de serviços de telefonia e Tv por assinatura é amplamente utilizado no Brasil por um grande número de usuários, que identificam muitas vantagens nesta modalidade de pagamento. Agora este inovador conceito também poderá ser utilizado por contribuintes do ICMS usuários da Nota Fiscal Fácil- NFF. A partir de legislação aprovada durante a 183ª. Reunião Ordinária do CONFAZ, Ajuste SINIEF 6/2021 que alterou o Ajuste SINIEF 37/2019, o App da Nota Fiscal Fácil (NFF) terá uma função para carga e recarga de créditos de ICMS pré-pagos, por meio de Guia Nacional de Recolhimento de Tributos Estaduais (GNRE), que pode ser paga através da Internet. Fato inédito no mundo das Administrações Tributárias, que vem para simplificar a vida dos contribuintes do ICMS. Com isso, o App da NFF que já permite ao caminhoneiro emitir seus documentos fiscais de transportes, diretamente do seu telefone, em uma segunda etapa de ampliação do projeto, prevista para o segundo semestre de 2021, uniformizará e facilitará o pagamento do ICMS sobre o frete nos 26 Estados e Distrito Federal. A capacidade de emitir seus próprios documentos, permite ao caminhoneiro reduzir custos e aumentar sua competitividade no mercado, o que lhes dá condições para prestar melhores serviços aos seus clientes, já que torna desnecessária a intermediação de atravessadores que diminui suas receitas de frete. O pré-pagamento do ICMS sobre o frete poderá ser realizado pelo próprio caminhoneiro ou por qualquer outra pessoa, inclusive pelo contratante do serviço, a partir da GNRE enviada pelo caminhoneiro utilizando os recursos de seu telefone, como aplicativos de conversas e de redes sociais, por exemplo. Alternativamente, o contratante poderá adicionar o valor correspondente ao ICMS devido ao adiantamento do serviço de frete pago ao caminhoneiro. Os créditos de ICMS Pré-pagos e vinculados ao CPF do caminhoneiro, serão automaticamente carregados no App da NFF, a partir da recepção e liquidação do pagamento da GNRE pela Sefaz da unidade federada de origem da prestação do serviço de transporte, permitindo a este gerar seus documentos fiscais de transportes (MDF-e/CT-e) com o valor do ICMS calculado e liquidado automaticamente pelo App, a partir do seu saldo disponível na base do sistema de arrecadação da Sefaz, devidamente transferidos para o App. Este importante recurso a ser agregado ao APP da NFF, tornará desnecessária uma prática muito comum na realidade do Transportador Autônomo de Cargas, que é a necessidade de deslocamento a uma das repartições fiscais da Secretaria de Fazenda de início da prestação do serviço de transporte, visando a emissão de documentos fiscais, cálculo e pagamento do ICMS sobre frete. Está importante simplificação não beneficiará apenas o segmento de transportes, pois já está em desenvolvimento o módulo do App da NFF que permitirá a emissão de documentos fiscais de mercadorias, emitidos por produtores primários de legumes, frutas e verduras. ENCAT: Fazer acontecer e inovação é a nossa marca. Se você não viu nossos posts anteriores sobre este tema, publicados nas redes sociais do ENCAT e Portal de DF-e, não deixe de acessar nossas publicações nos canais descritos abaixo: 1) MDF-e: O Suporte Digital da Transformação dos Serviços de Transporte no Brasil (01/04/2021) Twetter: http://www.encat.org/?p=1760 Facebook: Encat Brasil Portal DF-e SVRS: https://dfe-portal.svrs.rs.gov.br/MDFE/Noticias/2298 2) MDF-e: O Documento que Integra a Venda e a Entrega da Mercadoria (06/04/2021) Twetter: http://www.encat.org/?p=17686 Facebook: Encat Brasil Portal DF-e SVRS: https://dfe-portal.svrs.rs.gov.br/MDFE/Noticias/2302

Bom dia Galegobr, A sua contribuição foi aceita, vou enviar para o repositório em breve juntamente com as demais alterações feitas no componente devido a alteração do layout da NF-e.

Boa tarde, A alteração foi feita sim e enviada para o repositório. É bem provável que a sua unit tem alguma alteração, logo o Tortoise não atualizou ela.

Boa tarde, No manual esta escrito que devemos usar \s\n, mas o que tudo indica o provedor não compreende essa sequencia de caracteres para realizar a quebra de linha. Logo esquece esse sequencia. Você disse anteriormente que o provedor existe que seja enviado o caractere de quebra de linha: #13 Faça o seguinte teste: QuebradeLinha=#13

Boa tarde Paulo, Essa alteração na URL é só para essa cidade ou para todas?

Bom dia, Já enviei para o repositório.

Bom dia, Já esta no repositório. Quanto ao erro de consultar o lote vai ser necessário debugar para descobrir o porque ele não esta gerando no XML a tag do Protocolo com o seu numero.

Bom dia, O componente remove a quebra de linha que por ventura tenha no XML, pelo simples fato que o XML não pode ter o caractere de quebra de linha. Texto extraído do manual da ABRASF: Para reduzir o tamanho final do arquivo XML da NFS-e alguns cuidados de programação deverão ser assumidos: * não incluir "zeros não significativos" para campos numéricos; * não incluir "espaços" no início ou no final de campos numéricos e alfanuméricos; * não incluir comentários no arquivo XML; * não incluir anotação e documentação no arquivo XML (TAG annotation e TAG documentation); * não incluir caracteres de formatação no arquivo XML ("line-feed", "carriage return", "tab", caractere de "espaço" entre as TAGs); * para quebra de linha na exibição para os campos contendo caracteres Discriminacao e Outrasinformacoes, utilizar a sequência “\s\n”. As TAGs que permitirem valores nulos devem ser omitidas da estrutura XML a ser enviada quando seus valores forem nulos.