Italo Giurizzato Junior

Bom dia, Na sua maquina crie uma pasta chamada ACBrBranches. Depois configure o Tortoise para esta pasta com a mesma URL, mas no final dela em vez de Trunk2 coloque Branches. São dois repositórios um chamado Trunk2 e outro Branches.

Bom dia Diego, Veja este link: http://www.checkupdown.com/status/E500_pt.html

Bom dia Alecio, Todos os fontes de todas as pastas estão atualizados? Se sim, após atualizar os componentes foram reinstalados com o ACBrInstall_Trunk2? Marcou a opção para apagar os arquivos antigos? Recompilou a sua aplicação com a opção Build?

Bom dia Oliveira, No meu entendimento como só existe uma unica NF-e, você deve informar apenas a última cidade prevista para realizar as vendas. Não esqueça de quando o caminhão voltar deve fazer o encerramento do MDF-e.

Bom dia Filipe, Como não sou eu quem cuida do DACTE feito em Fast e Fortes Report, a minha sugestão é que você comente as linhas que estão gerando automaticamente a observação indesejada.

Se já existe o INI do provedor a principio não se faz necessário nenhuma alteração nos fontes (*.pas).

ALA, Abra os arquivos Cidades.ini e WebISS.ini e veja como foi feita a inclusão das demais cidades que se utilizam desse provedor.

Bom dia ALA, Pelas informações que tenho agora em dezembro/2017 inicia o projeto piloto nas seguintes cidades: Rio de Janeiro/RJ, São Paulo/SP, Brasilia/DF, Belo Horizonte/MG, Porto Alegre/RS, Maringá/PR e Maraba/PA. Em 2018 o objetivo é massificar, ou seja, expandir para as demais cidades brasileiras. Como dito a ideia é ter um único layout de XML e também um único Web Services responsável por recepcionar todas as NFS-e de todas as cidades brasileiras. Com relação ao layout não tenho informações como ele vai ser, estou torcendo para que seja o mesmo da NF-e, uma vez que este atende 98%. O que esta faltando é apenas as duas informações referentes a construção civil, ou seja, código da Obra e código ART e os dados do Tomador Intermediário. No meu entendimento bastaria criar um novo modelo diferente de 55 e 65, pois já são utilizados pela NF-e e NFC-e respectivamente e os dados acima que não tem campo especifico no layout do XML da NF-e, poderia muito bem serem informados de forma estrutura em: obsCont. No atributo xCampo informaríamos o nome da TAG, por exemplo: CodigoObra e na tag xTexto o seu valor. Vamos aguardar e torcer que isso se realize dessa forma, pois com pequenos ajustes no ACBrNFe vamos poder emitir NFS-e. Mas se for criado um layout diferente vamos estudar se vamos criar um novo componente ou vamos incluir esse layout no ACBrNFSe.

Boa noite ALA, A ideia é que todas as cidades brasileiras emitam a NFS-e segundo um mesmo layout. Teremos um único Web services que receberá todas as as NFS-e e disponibilizará para a prefeitura correspondente. Como será o layout não sei ainda.

Boa noite Pedro, Primeiramente o CT-e que você deseja emitir é CT-e Globalizado ou não? Se não for, favor incluir a linha abaixo na sua rotina que alimenta o componente: Ide.indGlobalizado := tiNao; Agora se for devemos ter a seguinte linha: Ide.indGlobalizado := tiSim; Outra coisa um CT-e globalizado pode ter um único Remetente com diversos Destinatários, neste caso as notas tem que possuírem diferentes destinatários. Por outro lado podemos ter diversos Remetentes com um único Destinatário, neste caso as notas tem que possuírem diferentes emitentes.

Boa noite Osvaldo, Alem de atualizar os fontes, você reinstalou os componentes? Se não reinstalar acredito que não aparece mesmo no Object Inspector.

Boa noite todos, Já encontra-se disponível o ambiente de homologação para as empresas do estado da Bahia testarem o BP-e. O estado da Bahia será atendido pela SEFAZ Virtual RS. Para realizarem os testes é necessário que as empresas entrem em contato com a SEFAZ do seu estado.

Boa noite ALA, Pelo que pude ver segundo a documentação o layout XML não segue o layout da ABRASF. Me desculpe, eu em particular não estou implementando nenhum provedor que não siga o layout da ABRASF. Visto que existe um projeto da NFS-e Padrão Nacional cujo projeto piloto esta previsto agora para dezembro/2017.

Boa noite ALA, De uma olha na procedure GerarValePedagio que se encontra na unit pmdfeMDFeW.pas A maneira de alimentar os dados mudou se tratando da versão 3.00

Boa noite Rodrigo, Você não encontrou? Temos um fragmento de código de coma fazer na pasta: ...\Exemplos\ACBrDFe\ACBrCTe O arquivo CartaCorrecao.txt foi disponibilizado em 17 de setembro de 2014

Boa noite Luis, Quais são as informações necessárias para emitir um CT-e de Anulação? E quando devemos emitir um CT-e de Anulação? As respostas para essas perguntas você encontra em: http://www.ophos.com.br/app/publicacoes/detalhe/ct-e-de-anulacao-e-substituicao/

Boa tarde Filipe, Ao ler a NT passou a desapercebido, muito obrigado pelo aviso, Para gerar a tag indAlteraToma basta incluir a seguinte linha: infCTeNorm.infCteSub.indAlteraToma := tiSim; ou infCTeNorm.infCteSub.indAlteraToma := tiNao para não gerar a tag.

Boa tarde a todos, Corrigi o pacote de instalação do componente e enviei para o repositório.

Dirlenio, Na versão 3.00 do CT-e esta previsto a tag: indAlteraToma = Indicador de CT-e Alteração de Tomador. Mas o componente ACBrCTe não esta gerando essa tag pois consta no manual a seguinte recomendação: Tag com efeito e utilização aguardando legislação, não utilizar antes de NT específica tratar desse procedimento. Sendo assim não vejo nenhuma alternativa de resolver o problema.

Bom dia a todos, Lembrem-se que o envio do CT-e é assíncrono, ou seja, ao enviar temos como resposta o numero do recibo que acusa o recebimento do lote de CT-e pela SEFAZ. Em seguida devemos realizar uma consulta informando o numero do recibo para saber o resultado do processamento do(s) CT-e que constam no lote enviado. Já o envio do CT-e OS é síncrono, ou seja, ao enviar temos como resposta o resultado do processamento, portanto não temos o numero do recibo e consequentemente não se faz necessário realizar a consulta através do numero do recibo. Espero ter ajudado.

Bom dia Jhonlenon, Só uma observação, o que você esta fazendo é a Manifestação do Destinatário e não Manifesto de NF-e. Temos que tomar cuidado, pois existe o Manifesto de Documentos Fiscais Eletrônicos - MDF-e, que se trata de um outro documento fiscal eletrônico que não tem nada haver com o evento de Manifestação do Destinatário. Fica ai a dica.

Bom dia Marília, Esse XML que você anexou trata-se do XML gerado pela primeira vez? Pois notei que o IE consta no grupo <rem>. Outra coisa, altere a linha que você carrega o XML para: CTe.Conhecimentos.LoadFromStream(st, False); O parâmetro False faz com que o XML não seja gerado novamente.

Bom dia, A regra G73 com a Nota Técnica 2017/002 versão 1.02 ficou mais clara, pois antes o texto era: Se Tipo de Serviço = “Serviço Vinculado a Multimodal” deve ser referenciado pelo menos um CT-e autorizado pelo OTM (infServVinc/infCTeMultimodal/chCTeMultimodal). Agora passou a ser: Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição) e Tipo de Serviço = “Serviço Vinculado a Multimodal” deve ser referenciado pelo menos um CTe autorizado pelo OTM (infServVinc/infCTeMultimodal/chCTeMultimodal). Chegamos a conclusão que um CT-e cujo tipo de serviço é Serviço Vinculado a Multimodal, o seu tipo só pode ser Normal ou de Substituição. O pessoal da SEFAZ ainda não entenderam que o seu objetivo é emitir um CT-e de Complementação de Valor cujo tipo de serviço é Serviço vinculado a Multimodal e pela regra G73 esse CT-e será rejeitado.

Bom dia Felipe, Primeiramente me preocuparia com a versão 3.00 do CT-e uma vez que a versão 2 só será aceita até o dia 04/12/2017, ou seja, até segunda feira. Em que sentido você deseja destacar o valor do Seguro? Você quer que ele seja impresso no DACTE ou faça parte da composição do valor do frete?

Boa tarde Andrei, Você pode mudar os valores das propriedades: Tentativas, IntervaloTentativas, AguardarConsultaRet. Tentativas se refere a quantidade de vezes que o componente vai consultar o Lote para obter o resultado do processamento. IntervaloTentativas é o tempo em milisegundos entre uma consulta e outra. AguardarConsultaRet é o tempo em milisegundos que o componente vai aguardar antes de realizar a primeira consulta ao Lote. Agora em em alguns casos chega demorar 2 horas, ai o problema é no provedor.