Italo Giurizzato Junior

Boa tarde Cleyton, Com a NFC-e isso não será possível, como você já sabe. A saída que vejo é emitir a NFC-e no decorrer do mês e no fechamento emitir uma Fatura relacionando todas as notas e o valor total. Essa fatura com certeza terá um boleto para o pagamento, pois tudo indica que o pagamento é mensal.

Boa tarde a todos, Quando alimentar um campo do componente com o CNPJ ou CPF, favor informa-lo sem a mascara.

Boa tarde shdw, Tudo indica que você pode ter um NFC-e conjugada, ou seja, produtos mais serviços. Pois não encontrei nenhuma regra que rejeite uma NFC-e com item de serviço. Mas lembre-se que deverá ter no minimo um item de produto e tem que haver um acordo firmado entre o município e a SEFAZ do Estado.

Boa tarde a todos, No que diz respeito a numeração sequencial do evento, devemos levar em consideração o seu tipo. Cada tipo de evento tem a sua numeração sequencial iniciada em 1, sendo assim vamos a um exemplo: Foi solicitado uma CC-e para uma NF-e a numeração sequencial do evento CC-e é 1 pelo simples fato dela ser a primeira. Caso tenhamos uma segunda CC-e a numeração sequencial será 2. Suponha que em seguida essa mesma NF-e venha ser cancelada, qual será o numero sequencial do evento de cancelamento? A resposta é simples: 1 Porque? Leia novamente a linha acima em negrito. Complementando o que Régys escreveu, também não existe mais o PathCan.

Bom dia Agnaldo, Entendo perfeitamente o seu desabafo. Mas note que a NT 2015/002 versão 1.00 no final da página 2 consta as seguintes datas: 01/10/2015 para homologação e 03/11/2015 para produção. Eu baixei essa NT no dia 28/07/2015 portanto 2 meses antes do inicio para homologação, prazo este suficiente para que nós fizéssemos as devidas alterações no componente e depois mais um mês para realizar os testes de envio com a nova TAG em ambiente de homologação. Já a NT 2015/002 versão 1.10 no final da página 3 consta que a data para o ambiente de produção foi prorrogada para 01/12/2015 e no final da página 2 diz que as regras de validação na SEFAZ vão começar a valer somente a partir de 01/01/2016. Isso significa que se você pode gerar ou não o XML com a nova TAG depois de 01/12/2015 sem nenhum problema, uma vez que a validação da mesma só vai ocorrer a partir de 01/01/2016, portanto ganhamos mais 2 meses para deixar tudo redondo. Eu baixei a versão 1.10 da NT no dia 19/10/2015, portanto quase 15 dias antes do previsto para entrada em produção informada pela versão 1.00 da mesma NT. Sendo assim não vejo nenhuma falta de respeito por parte do ENCAT, pois informou com antecedência que o prazo seria prorrogado. Não estou defendendo ninguém apenas sendo justo. Não sei quanto a você, mas eu, todos os dias de manhã visito os Portais Nacionais da NF-e, CT-e e MDF-e em busca de algum Manual, Nota Técnica ou Schemas novos. Tenho todos os PDFs baixados desta forma sei se tem algo novo ou não, caso afirmativo, baixo e leio para saber do que se trata. Se você não fizer isso, sempre será pego de surpresa.

Bom dia Diego, Não existe nada implementado no componente ACBrNFSe sobre esse consulta ao numero do último lote enviado, uma vez que esse método não faz parte do padrão ABRASF. A solução é bem simples, basta a sua aplicação fazer o controle efetivo tanto do numero do RPS quanto do numero do lote enviado para o provedor.

Bom dia Eduardo, Qual é o valor que você esta informando para indIEDest? Favor ler o item 3.7 que trata sobre a Identificação do Destinatário na página 20 da Nota Técnica 2013/005 versão 1.22

Bom dia, Simples os seus fontes estão desatualizados. Dentro da pasta ...\Fontes\ACBrDFe\ACBrNFe apague os arquivos: ACBrNFeServicos.INI e ACBrNFeServicos.RES e atualize todos os fontes de todas as pastas. Compile a sua aplicação com a opção Build.

Bom dia Thyago, Você não tem outro .RES antigo do ACBrNFeServicos em outra pasta?

Thiago, No meu entendimento: vTPrest é o valor total da prestação, ou seja, o valor total do frete o quanto o tomador do serviço vai pagar para que a mercadoria seja transportada. vRec é o valor a receber, supondo que vTPrest seja 100 reais e o tomador já pagou antecipado 30 reais o vRec seria a diferença, ou seja, 70 reais. Se o tomador pagou a vista e antes do transporte ser realizado o vRec é zero, por outro lado se ele vai pagar tudo depois do serviço ter sido executado, vRec é igual a vTPrest. vCarga é o valor da carga, ou seja, o valor que consta na nota fiscal dessa carga. vTotTrib é o valor aproximado do total dos tributos, não tem nada haver com o valor do ICMS que é calculado. Existe uma tabela onde temos um percentual para calcular esse valor. O problema agora é que o governo quer que apareça o valor aproximado dos tributos: Federais, Estaduais e Municipais, mas só temos apenas uma TAG que é vTotTrib. A solução é calcular individualmente esse valores, informa-los no campo de observação, soma-los e informar o total em vTotTrib. A tabela que me refiro você encontra uma para cada Estado na pasta: ...\Exemplos\ACBrTCP\ACBrIBPTax\tabela A coluna "tipo" se for 1 indica serviço, logo você terá que procurar qual é o serviço que mais se encaixa com a situação e se utilizar dos percentuais que estão nas colunas: NacionalFederal, Estadual e Municipal ou se for o caso: ImportadosFederal. Esse percentual deverá ser aplicado em vTPrest. Como dito logo no inicio esse é o meu entendimento.

Bom dia ncc, Isso não é nada, o pior que tem Estados exigindo a emissão do MDF-e para transporte de carga intermunicipal. A pergunta que faço é: Uma cidade que possui uma duzia de entradas como é o caso da minha, será que vai ter em cada uma delas um posto de fiscalização?

Bom dia João, Muito obrigado pela colaboração, já esta disponível.

Bom dia Thiago, Favor informar o nome da TAG assim fica mais fácil poder lhe ajudar.

Bom dia Isaac, Você leu a Nota Técnica 2015/002 versão de Agosto que trata sobre o Web Service de Distribuição de DF-e? Esta NT esta disponível no Portal Nacional do MDF-e.

Boa tarde Gilson, Atualizeis os schemas e corrigi a URL que estava no ACBrCTeServicos.

Boa tarde ALA, Mas foi exatamente que eu disse, a SEFAZ ainda não implementou as mudanças. Segundo esse último XML que você postou, não fez o que lhe pedi.

Boa tarde a todos, Gostaria de informar que o XML do RPS é gerado pela Unit pnfsNFSeW que no caso do Trunk2 se encontra na pasta ...\Fontes\ACBrDFe\ACBrFSe\PCNNFSe Procurei pela TAG ISSST no mesmo fonte que esta Trunk e depois no que esta no Trunk2, em ambos existe as linhas que criam esse grupo. Outra coisa o provedor Infisc não segue o padrão ABRASF. Já deixei claro em outras postagens que o meu objetivo é primeiro atender todos os provedores que seguem o padrão ABRASF versões 1.x e 2.x, isso representa por vota de 47 provedores. Desses 47 provedores, primeiro vamos disponibilizar os arquivos INI daqueles que necessitam somente do RPS assinado ou somente do Lote assinado ou nenhum dos dois assinados, ou seja 29 provedores. Os que necessitam que tanto o RPS quanto o Lote sejam assinados vão ficar por último, uma vez que será necessário efetuar alguns ajustes no componente para que isso ocorra, uma vez que nos primeiros testes o componente se recusou a assinar o lote pois detectava a presença de uma assinatura que no caso era do RPS. Por fim vamos nos debruçar sobre a meia duzia de provedores que não seguem o padrão ABRASF. Em anexo segue o INI do provedor Infisc com algumas alterações que juguei ser necessárias, mas isso não significa que vai funcionar. Infisc.ini

Bom dia Adriano, O componente possui uma propriedade chamada EmissaoPathNFe o valor padrão é False, experimente mudar para True. Faça um teste informe que a data da emissão é 30/10 e envie depois verifique onde o XML foi salvo.

Bom dia ALA, Notei que no seu XML consta o grupo <ICMSUFDest> e você esta enviando para o ambiente de homologação, correto? E a sua nota esta sendo rejeitada e o motivo é: Falha no Schema XML do lote de NF-e. Pois bem, essa mensagem não tem nada haver com os schemas que você esta usando para validar o XML antes de enviar. O problema esta na SEFAZ que ainda não implementou essas mudanças em seus Web Services. Experimenta gerar um novo XML sem o grupo <ICMSUFDest> para ver se a nota vai ser autorizada.

Bom dia Adriana, Vamos ver se eu entendi: O guindaste é um só e o mesmo foi desmontado para ser transportado por 3 caminhões? São 3 caminhões, cada um com o seu motorista ou é 1 caminhão (cavalo) e 3 carretas? Se é apenas um guindaste e foi desmontado e colocado em 3 caminhões e a nota que você se refere é uma NF-e, acredito que não seja possível emitir 3 CT-e fazendo referencia a mesma NF-e. No meu entendimento você vai ter que emitir apenas 1 CT-e e imprimir 3 vias e no campo de observações explicar que a carga total foi dividida e esta sendo transportadas pelos veículos de placas: A, B e C. Caso alguém tenha alguma informação mais correta por favor postem.

Boa tarde Roberto, Você não pode alterar o conteúdo de uma TAG principalmente se ela faz parte do bloco que será assinado. Ao assinar um XML é gerado um DigestValue, uma especie de CheckSum, se você altera o conteúdo de uma TAG o DigestValue se torna inválido.

Rodrigo, Na primeira ( ...\Exemplos\ACBrDFe\Schemas\NFe ) tomos os schemas que você deve usar. Na segunda vamos manter uma cópia zipada das versões anteriores.

Boa tarde, Foram feitas varias alterações, você atualizou os fontes e compilou a sua aplicação com a opção Build? Se não fez, por favor atualize os fontes, compile e teste novamente.

Boa tarde a todos, Esse problema de validação já foi resolvido a uns 10 dias atras, favor atualizar todos os fontes de todas as pastas e compilar a aplicação com a opção Build. E utilize os Schemas que encontram-se dentro da pasta: ...\Exemplos\ACBrDFe\Schemas\NFe

Rodrigo, O emitente do CT-e, no caso a transportadora, mais o tomador do serviço, ou seja, quem vai pagar o frete, mais o contador devem ter os seguintes arquivos: <chave>-cte.xml ===> XML referente ao CT-e, assinado e com o protocolo de autorização, esse XML é um documento fiscal eletrônico valido juridicamente. <tipoevento><chave><seq>-procEventoCTe.xml ===> XML referente ao processamento de um evento, esse XML contem a solicitação do evento, esta assinado e com o protocolo acusando que o evento foi registrado e vinculado ao CT-e, portanto também é um documento fiscal eletrônico valido juridicamente. Esses dois arquivos tanto o emitente quando ao tomador do serviço devem possuir e guarda-los pelo tempo estabelecido na legislação. O contador vai utiliza-los para fazer a escrita fiscal, etc. O *-procEventoCTe.xml que devemos enviar para o contador até onde sei é somente o de cancelamento, mas é bom conversar com ele.