Italo Giurizzato Junior

Bom dia Robinho, Desculpe pela informação equivocada. O grupo <infDoc> onde consta as informações sobre os documentos originários é de nível 2, isso significa que esse grupo esta dentro de um grupo de nível 1 que por sinal é o <infCTeNorm>. Se você vai emitir um conhecimento complementar será gerado o grupo <infCteComp> que por sinal também é de nível 1, e tem um detalhe se o grupo de informações do CT-e complementado é gerado o de informações do CT-e Normal não é. Portanto não vai ser gerado o grupo <infDoc>, isso significa que não há necessidade de informar os documentos originários em um CT-e de complementação. Devemos sim informar a chave do CT-e a ser complementado e esta informação aparece dentro do grupo <infCteComp>.

Bom dia Elcyberg, O que vem a ser esse erro 219? No XML da NFC-e como esta aparecendo o valor de dhEmi? A dhEmi antes de ser convertida para HEX é preciso que ela seja exatamente igual ao conteúdo da TAG dhEmi que por sinal possui a Data, Hora e o UTC, exemplo: "2014-05-05T08:00:15-03:00"

Bom dia Helio, No manual não existe as dimensões de cada quadro, logo você pode alterar o tamanho dos mesmos, desde que não prejudique a leitura das informações.

Bom dia picyka, Você tem os Schemas do provedor Betha que contempla uma lista de serviços em vez de apenas um? Pois os Schemas que temos não contempla.

Bom dia Marlon, Vamos o que esta escrito na página 28 da NT 2013/005 versão 1.03: O processamento síncrono do Lote corresponde a entrega da resposta do processamento das NF-e do Lote, sem a geração de um Recibo de Lote para consulta futura. A resposta de forma síncrona pela SEFAZ Autorizadora só ocorrerá se: - a empresa solicitar e constar unicamente uma NF-e no Lote; - a SEFAZ Autorizadora implementar o processamento síncrono para a resposta do Lote de NF-e. Só vamos poder utilizar o modo síncrono, se a SEFAZ autorizadora implementar esse modo de processamento, caso contrario devemos continuar o modo assíncrono. Se a SEFAZ autorizadora que você utiliza implementou o modo síncrono, você não tem com o que se preocupar, pois lembre-se que neste modo só podemos enviar um lote contendo somente uma NF-e, caso contrario teremos que enviar no modo assíncrono. O comando Enviar do componente ACBrNFe possui 3 parâmetros, são eles: numero do lote, imprimir o DANFE, modo de envio, vamos aos exemplos: Enviar(nLote, True, False) - Envia o lote no modo assíncrono (terceiro parâmetro = False) e imprime o(s) DANFE(s) (segundo parâmetro = True) Enviar(nLote, True, True) - Envia o lote no modo síncrono (terceiro parâmetro = True) e imprime o DANFE (segundo parâmetro = True) Conclusão, você não precisa solicitar nada na SEFAZ Autorizadora, apenas verificar se a mesma disponibilizou os dois modos ou não. Espero ter ajudado.

Bom dia Helio, Sei que colocar cada valor em uma linha fica fácil de enxergar, mas se você colocar o valor do vale alimentação e do vale transporte na mesma linha, vai ganhar uma linha. Estude a possibilidade de colocar mais de uma informação por linha.

Bom dia gguimp, Testei os seus 3 XML, gerando o DACTE com o recibo configurado no cabeçalho e no rodapé. Os 6 DACTE gerados tem apenas 1 página. Por favor certifique-se se os seus fontes estão atualizados. Verifique também a configuração da impressora, pois aqui estou utilizando o tamanho A4.

Bom dia Rodrigo, Foi enviado uma alteração, por favor atualize os seus fontes e teste novamente.

Bom dia João, Para resolver o problema de Componente DANFSE não associado, basta termos os dois componentes: ACBrNFSe e ACBrNFSeDANFSeQR no mesmo form existe uma propriedade em ACBrNFSe chamada DANFSE onde você seleciona o outro componente. Outra coisa, o componente sempre gera o XML do RPS e envia para o Web Services que por sua vez processa e retorna o XML da NFS-e caso esteja tudo correto. Certifique-se que ao carregar o XML você realmente esta carregando o da NFS-e e não do RPS, uma vez que quem tem o código de verificação é o XML da NFS-e.

Bom dia Asterix, E o XML da NFS-e retornado pelo Web Services, a alíquota esta com qual valor: 0.02 ou 2 ?

Robinho, No CT-e complementar temos que informar a chave do CT-e que esta sendo complementado e como postado anteriormente, também as chaves da NF-e que se refere ao documento originário, ou seja, o documento emitido pelo remetente da carga. Na mesma NT na página 147 temos a definição do grupo infCteComp e seu elemento chave onde devemos informar a chave do CT-e complementado.

Robinho, Segundo a NT 2013/013 página 136 temos a estrutura do XML onde temos o grupo infDoc, temos: Descrição: "Informações dos documentos transportados pelo CT-e. Opcional para Redespacho Intermediario e Serviço vinculado a multimodal." Observação: "Poderá não ser informado para os CT-e de redespacho intermediário. Nos demais casos deverá sempre ser informado."

Bom dia Robinho, Na versão 2.00 do CT-e as NF-e de uma mercadoria que vai ser transportada deve ser informada sim. O que mudou? Na versão 1.04 os documentos originários, ou seja, as notas emitidas pelo remetente da mercadoria fica dentro de um grupo que por sua vez fica dentro do grupo remetente. Na versão 2.00 o grupo que contem os documentos originários esta fora do grupo remetente.

Boa tarde Marco, Se o erro é que o teCancelamento não esta definido, o problema é simples de resolver: Inclua em Uses a unit pcnConversao

Boa tarde Rigotti, Sim, o Source Forge esta passando por uma instabilidade. Por favor post como anexo os fontes que você alterou.

Boa tarde Robinho, Se a a sua empresa é uma transportadora ela com certeza emite CT-e. Se o caminhão sair com uma carga fracionada, ou seja, vários remetentes e vários destinatários e o transporte será realizado para fora do estado, isso implica na emissão do MDF-e. Lembre-se que quando emitimos CT-e de carga fracionada não informamos no mesmo o veículo e o motorista. É ai que entra o MDF-e, pois neste devemos informar o veículo, o motorista e os CT-e referente a carga fracionada que consta no veículo. Se toda a carga resultou em 35 CT-e, devemos informar as 35 chaves no MDF-e. Ao enviar o MDF-e para SEFAZ a mesma vai checar se as chaves são validas, isso significa que os CT-e foram previamente emitidos e todos foram autorizados pela SEFAZ. Se a carga vai de São Paulo/SP até Campinas/SP, temos o transporte dentro do estado logo não há necessidade de emitir o MDF-e, mas se desejar emitir pode. Para fora do estado, é obrigatório a emissão do MDF-e. Se toda a carga que consta no veículo vai para um único destinatário temos então um transporte "Lotação", neste caso no CT-e devemos informar o veículo e o motorista, sendo assim não se faz necessário a emissão do MDF-e, mesmo que o transporte seja para fora do estado. Espero ter respondido todas as suas questões.

Boa tarde João, O componente ACBrNFSe possui 3 formas de envio: 1. Enviar -> envia um lote de até 50 RPS 2. EnviarSincrono -> envia um lote de até 50 RPS 3. Gerar -> envia somente um RPS Qual deles você usando? ou coisa dependendo do provedor algumas dessas opções podem não estar disponível. Com relação a mensagem de Componente DANFSE não associado significa que você não relacionou o componente ACBrNFSe com o ACBrNFSeDANFSE responsável pela impressão do DANFSE.

Robinho, O MDF-e deve ser emitido quando a carga é fracionada e o transporte for interestadual. Isso é valido para as transportadoras e para as empresas que emitem NF-e e realizam o transporte da própria mercadoria vendida. Se tratando de uma transportadora o MDF-e só vai constar a relação dos CT-e. Acho estranho esse "regime especial" onde você pode emitir o CT-e 10 dias após ter ocorrido o transporte e não precisar emitir o DACTE. Como que fica a fiscalização da carga sem nenhum documento emitido pela transportadora? Alguns emitentes de NF-e até informam qual é a transportadora e a mesma é impressa no DANFE, neste caso temos um Documento Auxiliar informando quem é o Remetente quem é o Destinatário e quem vai transportar a mercadoria, mas não são todos que fazem isso. Resumindo se você não emite o CT-e antes do caminhão partir, não tem como emitir o MDF-e e consequentemente quando os postos de fiscalização nas fronteiras entre um Estado e outro começar a exigir o MDF-e para facilitar a checagem da carga, com certeza vocês vão ter problemas.

Bom dia Ramalho, Quanto ao uso dos Web Services NfeAutorizacao e NfeRetAutorizacao é feita de forma automática pelo componente. E já foi implementado a um bom tempo. Estamos aguardando as URLs dos Web Services tanto de homologação quanto de produção do Ceará e as URLs de produção de Minas Gerais e Paraná, para que possamos finalizar a implementação. Com relação ao envio do Lote Zipado nada foi implementado ainda.

Rômulo, Eu não utilizo o ACBrInstall, utilizo os pacotes para instalar, logo não sei o que pode estar ocorrendo.

Rômulo, Você alterou no Tortoise a URL para baixar os fontes? Caso negativo, por favor, pesquise no fórum por atualização forçada, você vai encontrar um passo a passo de como proceder.

Bom dia Fernando, A minha sugestão é migrar na virada do mês, para que todos os CT-e emitidos dentro do mês tenham a mesma versão.

Bom dia leufmt, // Configurações -> Arquivos ACBrNFe.Configuracoes.Arquivos.AdicionarLiteral := True; ACBrNFe.Configuracoes.Arquivos.EmissaoPathNFe := True; ACBrNFe.Configuracoes.Arquivos.PastaMensal := True; ACBrNFe.Configuracoes.Arquivos.PathNFe := sPath; // Exemplo: C:\Sistema\XML sPathMensal := ACBrNFe.Configuracoes.Arquivos.GetPathNFe(0); ACBrNFe.Configuracoes.Arquivos.PathInu := sPathMensal; ACBrNFe.Configuracoes.Arquivos.Salvar := True; ACBrNFe.Configuracoes.Arquivos.SalvarCCeCanEvento := True; ACBrNFe.Configuracoes.Arquivos.PathEvento := sPathMensal; // Configurações -> Geral ACBrNFe.Configuracoes.Geral.FormaEmissao := teNormal; ACBrNFe.Configuracoes.Geral.PathSalvar := sPathMensal; ACBrNFe.Configuracoes.Geral.PathSchemas := sPathSchemas; ACBrNFe.Configuracoes.Geral.Salvar := True; Teste desta forma.

Bom dia Robinho, Se você tem todos os dados pertinentes ao transporte da carga salvos no banco de dados, não tem muito o que esquentar a cabeça. Primeiro um detalhe muito importante: A chave é composta por 44 dígitos sendo que os últimos 9 dígitos são: 8 referente ao valor de cCT e 1 referente ao Dígito Verificador. Alguns desenvolvedores atribuem a cCT o mesmo valor de nCT, esta errado, por dois motivos, primeiro o cCT possui apenas 8 dígitos e o nCT possui 9, segundo o cCT trata-se de um código e é recomendando pela SEFAZ que este código seja um número aleatório. Sendo assim a minha dica é ter na estrutura da tabela que contem os dados do Conhecimento, um campo chamado CodCT por exemplo. Ao incluir o registro no banco de dados, a sua rotina gera esse código, lembre-se que ele não pode ser zero e armazene no campo CodCT. Ao alimentar o componente devemos atribuir a cCT o valor armazenado no campo CodCT, desta forma a chave a ser gerada pelo componente sempre será igual. Então como fica a solução para gerar novamente o XML que acidentalmente foi excluído do disco: 1. Alimentar o componente com os dados armazenados no banco de dados. 2. Executar o comando Assinar, pois este vai gerar o XML e assinar o mesmo. 3. Realizar a consulta da situação atual, com esse comando o XML assinado vai receber o protocolo de autorização, desde que a propriedade AtualizarXML esteja com o valor True. Pronto temos o XML assinado e protocolado salvo em disco novamente. Espero ter ajudado.

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