Italo Giurizzato Junior

Boa tarde Mark Apollo, Já baixei e fiz uma leitura rápida. As alterações são pequenas no componente para que o mesmo possa atender essas novas modalidades de envio em contingência. Mas esta faltando quais são as UFs que serão atendias pela SVC-AN e pela SVC-RS. Sem essa relação não é possível começar as alterações no componente.

Boa tarde Elaine, A CC-e que você enviou e que por sinal você postou, note que esta assinado e protocolado e acusa que foi vinculado ao CT-e. Outra coisa essa CC-e foi enviada para o ambiente de homologação (teste), em qual ambiente você esta consultando? Lembre-se que pode ser algum problema na SEFAZ, pois a versão 2.00 começou a poucos dias e o pessoal da SEFAZ ainda estão aparando as arestas.

Boa tarde Jairo, Favor atualizar os fontes e testar novamente.

Boa tarde, Você esta com todos os fontes atualizados? Inclusive os fontes do programa exemplo? Acabo de realizar um teste e não tive nenhum problema. Quando você seleciona a cidade no programa exemplo, você clica no botão salvar configuração? Lembre-se toda alteração nas abas de configuração do programa exemplo para serem validas tem que salva-las.

Boa tarde Andreza, O ns4 que aparece em alguns XMLs das NFS-e são prefixos, exemplo: Em vez da TAG ser gerada da seguinte forma: <Email> é gerada com o prefixo: <ns4:Email> Você esta usando o componente ACBrNFSe para qual cidade?

Boa tarde, Se o erro que você se refere é do seu outro post, a resposta esta lá.

Boa tarde Easysoft, Segundo o Manual do CT-e versão 2.00, páginas 138 e 139 temos a TAG infUnidCarga como sendo filha da infUnidTransp. Sendo assim deve-se informar primeiro o tipo da unidade de transporte (rpUnidTransp) e a identificação da unidade de transporte (idUnidTransp) e depois as informações das unidades de carga - TAG: infUnidCarga

Boa tarde Udenilson, Até onde sei, no caso da NFC-e quando o lote tem apenas 1 NFC-e o envio é Sincrono, por outro lado quando tem 2 ou mais NFC-e no lote o envio é Assincrono.

Boa tarde Lucio, Realmente a rotina estava errada. Obrigado pela colaboração. A correção já esta disponivel.

Boa tarde Graça, É bem provavel ser um BUG no validador da SEFAZ-RS.

Boa tarde a todos, No CTe temos que informar o documento originário que pode ser dos seguintes tipos: NF comum (papel), NF-e ou Outros. Um CTe pode ter mais do que um documento originário, mas pelas regras de validação contidas nos schemas, todos os documentos originários incluidos no CTe tem que ser do mesmo tipo. Se for informado 5 documentos originários, todos tem que ser: NF comum ou NF-e ou Outros. Não pode misturar os tipos. Isso explica o fato do programa emissor gratuido ter incluido apenas o útimo documento incluido, pois os demais eram de tipos diferentes e ele foi eliminando os anteriores da geração do XML.

Boa tarde Aprendiz_ce, Se tratando de NFS-e, por favor seja claro nos seus questionamentos, pois o que você postou praticamente ninguem vai conseguir lhe ajudar. Procure sempre, informar, para qual cidade esta emitindo a NFS-e, e qual funcionalidade esta usando para gerar o XML (Enviar, Gerar, GerarLote ou EnviarSincrono). Sem essas informações fica dificil ajudar.

Boa tarde Dorian, Favor atualizar os fontes e tentar novamente.

Boa tarde Akai, Fontes atualizados. Muito obrigado pela colaboração.

Boa tarde, Os fontes alterados já estão disponiveis no SVN. Muito obrigado pela colaboração.

Boa tarde lexishome, O DACTE que você esta querendo imprimir se refere a um XML da versão 2.00 ou da 1.04? Se você alterou o arquivo ACBr.inc para que o componente passa a gerar o XML segundo a versão 2.00 o DACTE vai pelo mesmo caminho. Mas se você tentar visualizar ou imprimir um DACTE agora compilado para a versão 2.00, cujo XML foi gerado na versão 1.04 vai ocorrer esse problema, não vai aparecer os documentos originários.

Fechado por duplicação

Fechado por duplicação.

Boa tarde, Você não errou, o componente não esta errado, simplismente a SEFAZ esta criticando uma informação que ao meu ver não deveria se tratando de ambiente de homologação. Para testar em vez de informar a chave de uma NF-e informe os dados ficticios de uma NF ou outro tipo de documento, por exemplo uma declaração. Nos meus testes sempre informo os dados de uma declaração e não de uma NF-e e não tive problemas. Lembrando, nos meus testes, ambiente de homologação.

Boa tarde, Faça as alterações nos fontes e realize os testes, caso resolva os problemas, por favor zipa os fontes e post eles aqui no fórum como anexo.

Boa tarde Chico, Alteração feita e já disponibilizada.

Gabriel, Lotação => 1 Remetente, 1 Destinatário Quando você tem por exemplo: 2 ou mais Remetentes, 1 Destinatário => CT-e Globalizado, para emitir o CT-e Globalizado a transportadora precisa obter o Regime Especial, caso contrario não pode. No DACTE sempre será impresso o RNTRC da transportadora e quando for Lotação ao informar os dados do veículo se este for de terceiro devemos informar o RNTRC do terceiro. Neste caso vai aparecer os dois RNTRC no DACTE.

Marcos, Desculpa, quando vi Item achei que você queria a tabela que contem os códigos e descrição dos Item de Serviço. No que se refere a criação das tabelas no banco de dados para armazenar os dados da nota, etc. não vou poder lhe ajudar pois não tenho nenhuma aplicação que utiliza o ACBrNFSe. Eu apenas ajudo no desenvolvimento do componente.

Boa tarde, Favor atualizar os fontes e testar.

Boa tarde Chico, A chave é formata de tal forma para facilitar a identificação de todos os campos que a compõe. Quanto a linha mencionada não sei, o meu cliente nunca emitiu um CT-e Substituido. É preciso fazer testes com e sem o tcSubstituido para ver como que fica.