Italo Giurizzato Junior

Boa tarde a todos, Como responsável pelas alterações no componente ACBrCTe, gostaria de colocar a minha posição sobre esse assunto. Quando comecei a usar os componentes ACBr foi um pouco antes do lançamento da versão 2.00 da NF-e. Na época os responsáveis pelo componente resolveram em criar um novo componente o ACBrNFe2 que era destinado a versão 2.00 em contra partida ao ACBrNFe que era destinado a versão 1.11 se não me falha a memória. Mas tinhamos um problema, internamente o componente tinha o mesmo nome ou seja ACBrNFe1, portanto não era possivel ter os dois instalados no mesmo Delphi. Isso sem falar que muitos compilavam o pacote PCN2 e depois queriam compilar o ACBrNFe e vice-versa. Instalava o ACBrNFe e queriam emitir a NFe na versão 2.0 Esses são os problemas que observei lendo o fórum na época. Logo o que é mais fácil, alterar o ACBr.inc e compilar a sua aplicação com a opção Build ou ter que remover um componente para instalar outro? Sei que poderiamos criar um segundo componente e alterar o nome interno dele, por exemplo ACBrCTev2 desta forma poderiamos ter os dois componentes instalados no mesmo Delphi. Mas resolvi repetir o procedimento adotado quando a versão do CT-e mudou de 1.03 para 1.04, me digam foi muito traumatico essa mudança? Os clientes reclamaram muito, por ter que usar um programa a parte, para poder ler o XML e imprimir o DACTE da versão anterior? Já postei em outros tópicos, como ficaria a rotina na hora de alimentar o componente em função da nova versão. Eu lanço mão da diretiva de compilação. Portanto a minha aplicação hoje é capaz de gerar XML do CT-e nas versões 1.04 ou 2.00 bastando alterar o ACBr.inc e compilar com o Build. Não preciso trocar uma virgula se quer na minha aplicação. Quem sou eu em dizer o que é certo o que é errado, apenas adotei uma solução, me desculpa se ela deixa a desejar em alguns aspectos.

Boa tarde Robson, Tome como base o programa exemplo, no que diz respeito a configuração do componente.

Boa tarde Igor, Sim, toda e qualquer alteração nos dados do manifesto há necessidade de realizar o encerramento e fazer um novo. Seja pela troca do motorista, troca do caminhão, alteração no conteudo da carga, tem que fazer um novo. Como o meu cliente não utiliza o MDF-e, não sei lhe dizer com toda segurança se o segundo a ser emitido tem que ser a unidade de São Paulo ou a unidade de São José dos Campos.

Bom dia Luiz, O problema é simples, analisando o código fonte do ACBrNFeMonitor ( programa que você utiliza para emitir o CT-e ) não possui as linhas necessárioas para alimentar o componente com os dados necessários para um CTe de Complementação de Valores. Por favor, aguarde mais um pouco até o pessoal implementar.

Bom dia Udenilson, Foi feito a principio para que o XML do RPS fosse salvo segundo a data de Emissao, mas para isso devemos atribuir o valor True a propriedade EmissaoPathNFSe. Depois implementei essa possibilidade de salvar também o XML da NFSe. Favor verificar se os seus fontes estão atualizados. E em qual fonte e linha, você fez a alteração para manter o prefixo, tc:?

Bom dia a todos, Querem uma solução? Faz uma denuncia, junto ao fisco, SEFAZ, etc, informando que o emitente da NF-e se recusa a disponibilizar o XML assinado e protocolado ao destinatário da carga e ou a transportadora responsável pelo transporte da mesma. Sendo que a obrigatoriedade esta muito bem clara no Ajuste SINIEF 07/2005, no Paragrafo 7, inciso I e II da Cláusula sexta: (...) § 7º Deverá, obrigatoriamente, ser encaminhado ou disponibilizado download do arquivo da NF-e e seu respectivo Protocolo de Autorização de Uso: I - ao destinatário da mercadoria, pelo emitente da NF-e imediatamente após o recebimento da autorização de uso da NF-e; II - ao transportador contratado, pelo tomador do serviço antes do início da prestação correspondente. (...) link do Ajuste na integra: http://www.fazenda.gov.br/confaz/confaz/ajustes/2005/AJ_007_05.htm

Bom dia Luiz, Se tratando de tributação, aconselho você consultar o contador a transportadora. Inclusive ele poderá orientar no que diz respeito ao texto, se há necessidade ou não.

Bom dia Marcio, Muito obrigado, solução adotada e já disponibilizada.

Bom dia Oneide, Se você esta usando o DANFSE em Quick Report, imprimi sim a tarja NFS-e CANCELADA. Inclusive acabei de fazer um teste usando o XML que você postou e a tarja foi impressa. Fiz agora uma alteração para imprimi-la com uma fonte maior, para ficar mais visivel.

Bom dia, Quando fiz as alterações no componente ACBrNFe para poder emitir a NFC-e as URLs que me passaram foram as da SEFAZ-AM. Favor entrar em contato com a SEFAZ-MT e solicitar as mesmas para que possamos atualizar o componente.

Bom dia ALA, Se a versão do seu Quick Report não for a 5 você deve remover o QR5RunD2007 da lista de requeridos que encontra-se no pacote de instalação: ACBrNFSeDanfseQRprk

Bom dia Diego, Não entendi, o que você fez, o arquivo chamado: 5RPS.xml, você editou colocando o código para poder enviar, é isso? Você esta alimentando a propriedade CodigoMunicipio? Uma coisa é você configurar o componente com o código do municipio, e outra é você alimentar a propriedade: NFSe.Servico.CodigoMunicipio

Bom dia Luiz, Você não gera o XML da NFS-e e sim do RPS, que gera o XML da NFS-e é o WebService. Para obter novamente o XML de uma NFS-e, deve-se realizar uma consulta.

Bom dia Eliene, Você não utiliza o componente ACBrCTe? O XML que você deseja se refere ao qual versão? Qual é o problema que você esta enfrentando?

Bom dia Alexandre Krepe, Esta sim, você alterou o arquivo ACBr.inc, comentando a diretiva de compilação PL_104 e descomentando a PL_200 ? Sem essa alteração o componente continua a gerar o XML segundo a versão 1.04.

Bom dia Jonathan, Faça uma cópia dos seus fontes. Atualize e teste novamente.

Bom dia idez, Favor atualizar os fontes, pois já existe uma condição que faz com que o techo que você comentou não seja executado quando o provedor é o Thema.

Bom dia João, Realmente o DACTE feito em Quick Report ainda não tem uma band para imprimir os dados de produtos perigosos. Reforço o seu pedido, caso alguem já tenha implementado e queira compartilhar, por favor post como anexo, os fontes aqui no fórum.

Bom dia Anderson, Ao emitir um CTe devemos informar alguns dados do documento originário que pode ser uma NF comum de papel ou uma NF-e ou outro tipo de documento. Os dados a serem informados dependendo de cada tipo de documento originário consta no manual. Uma coisa é certa se o documento originário é uma NF-e, não podemos lançar como sendo uma NF comum de papel, logo esse sistema antigo que você se refere esta errado. Sei que no caso da NF-e temos que informar apenas a chave da mesma. E como que fica na hora de calcular o valor do frete? Vamos imaginar que o frete é calculado levando em consideração o peso, por exemplo. A minha aplicação quando seleciono NF-e como documento originário, é solicitado ao usuário a digitação da chave, valor total da nota, peso e quantidade de volumes. A chave para ser incluida no XML, os demais dados, são salvos no banco de dados e são utilizados para calcular o frete. Se a tabela que calcula o frete leva em consideração o peso, este foi informado, se utiliza a quantidade de volumes, também temos essa informação. Espero ter ajudado.

Bom dia Tora, Ao configurar o componente com o código da cidade de Betim o componente vai gerar o XML conforme o schema do Ginfes, mas para que seja validado há necessidade de você configurar o componente apontando para a pasta que contem os schemas do Ginfes.

Bom dia Udenilson, Portal Nacional da NF-e / Documentos / Manuais / Manual de Especificações Técnicas da Contingência Offline versão 1.2 Página 2, segundo paragrafo do item 1 - Conceito e Modelo Operacional da Contingência Offline para NFC-e. Acredito que isso já responde a sua duvida, mas leia com atenção as 7 páginas desse manual, tem bastante coisa interessante.

Bom dia Douglas, Primeiramente a sua pergunta foi respondida pelo nosso colega Mark Apollo. Segundo, crie o abito de vitar diariamente os Portais Nacionais da NF-e, CT-e e MDF-e. Baixe os PDFs dos Manuais, Notas Técnicas e Ajustes SINIEF, recem publicados e leia com muita atenção. Desta forma você vai montando uma documentação técnica e normas legais. Com isso você tem condições de mostrar ao seu cliente, o que pode e o que não pode. Um forte abraço e boa leitura.

André, Isso é ridiculo, os caras não querem saber de trabalhar, ou simplismente não sabem como resolver o problema. Faça um teste, entre em contato novamente e diz que utiliza o emissor gratuido da SEFAZ para emitir a NF-e e apresenta a eles o problema do cancelamento. Vamos ver qual vai ser a resposta deles.

Boa tarde Edudidu, Já chegou a conversar com algum contador? Acredito que ele é a pessoa mais indicada a lhe responder essas questões.

Boa tarde a todos, Na minha opnião, o programa exemplo, trata-se de um exemplo e não uma solução, a ser utilizado pelos colegas que necessitam emitir a NFS-e. É por isso que foi criado o arquivo Cidades.rtf com a relação das cidades implementadas. Se quero utilizar o componente para cidade XYZ devo inicialmente pesquisa-la no arquivo Cidades.rtf, se constar da relação vou ficar sabendo que o componente emiti a NFS-e para essa cidade e quem é o provedor que atende ela. Os programas exemplos da NFe, CTe e MDF-e por ser a nivel de Estado, foi incluido no combobox todos eles, visto que não chega a 30. Agradeço todas as suas colaborações LVR, o componente avançou bastante com a sua ajuda. Quanto a incluir todas as cidade no combobox, podemos até incluir, mas não vejo como sendo algo de extrema necessidade. Simplificaria, sim, como você relatou o componente retornaria que a cidade ainda não é atendida e não precisariamos atualizar o arquivo Cidades.rtf