nolher

Boa tarde pessoal, Abandonaram esse tópico? ____________________________ Nilton Olher

Boa tarde pessoal, Abandonaram esse tópico? ____________________________ Nilton Olher

Boa tarde pessoal, E aí alguma novidade referente a esse tópico? ____________________________ Nilton Olher

Boa tarde pessoal, E aí alguma novidade referente a esse tópico? ____________________________ Nilton Olher

Bom dia a todos, Nos deparamos com essa situação também. Realmente concordo que não seja tão essencial assim a visualização de todos os CT-es antes de enviar para impressora, mas o difícil é convencer o usuário desta função totalmente desnecessária, a qual a muito tempo ele já usa. Estamos com nosso CT-e em faze de desenvolvimento e teste em um cliente em especifico, que esta nos auxiliando na parte de teste. No âmbito da impressão de vários CT-es foi a primeira coisa que ele nos solicitou, e diante de nossas argumentações, veio a frase: " - Se temos a visualização porque não usa-lá." Procurando e avaliando outros tópicos, pude observar esse problema em outras situações, como o caso de poder selecionar a impressora que será enviado para emissão. Analisando as rotinas e fontes, vi como foi feito a rotina com atualização de tabelas para um único conhecimento, possível de realizar uma alteração é totalmente possível, o caso é avaliar o custo e beneficio desta alteração que irá demandar uma grande alteração. Existe pontos do desenvolvimento do componente que tenho dificuldades de entender como foi feito, sendo assim não me arriscarei em uma empreitada desse porte. Teremos que aguardar o posicionamento do Italo e Cia, para avaliar melhor o impacto de um mudança dessa. ____________________________ Nilton Olher

Boa tarde Italo, Conforme já havia comentado eles deixam mais dúvidas do que resposta. A nomenclatura adotada pelo componente ACBrCTe no caso de Cancelamento e Inutilização o arquivo XML final esta com nomenclatura diferente, pois adota a chave como base da nomenclatura mas é colocado no final -ProcCancCTe e -ProcInutCTe, justamente a parte de nomenclatura usada no Item 11.1, mas no caso do arquivo principal do cte é não é utilizado essa parte de nomenclatura. O paragrafo 2 comentado acima trata da distribuição dos arquivos entre o emitente e o Destinatário/Tomador do Serviço e o paragrafo 3 trata da guarda desses arquivos pelo emitente e Destinatário/Tomador do Serviço e faz referencia a nomenclatura a ser adotada e fica claro que é a que consta no item 5.2 do Manual. Aqui o termo "distribuição" aparece no manual no item 10.1 e se refere a forma como o emitente vai disponibilizar os arquivos para o tomador do serviço (CTe) ou para o destinatário (NFe) a nomenclatura que se refere ao item 11.1 diz respeito ao compartilhamento de arquivos entre a SEFAZ e a RFB. Outra coisa no final do item 5.2 que trata da padronização de nomes dos arquivos, temos o seguinte paragrafo: "O padrão de nomenclatura também facilitará o aplicativo visualizador do CT-e." Essa última frase realmente esta no manual, mas não poderia dizer que a informação do perguntas e resposta do Programa Emissor, deva ser diferente do manual. Em sintase há mais dúvidas do que respostas. Ainda me mantenho na minha opinião de adotar a possibilidade de gerar das duas formar. Sem mais para o momento, Agradeço a atenção, Nilton Olher

Muito Obrigador Italo. Vou proceder as Alterações.

Então a peguntar permanece: É possível cancelar um CT-e sem ter o XML de Origem? Desde já Antecipo agradecimento, Nilton Olher

Bom, pessoal como podemos ver é uma questão que até mesmo eles não tem uma definição clara e direta, apenas fazem conjunturas. Mas, diante de citarem pela segunda fez o Item 11.1 e o padrão recomentado pelo Programa Emissor, mantemos a nossa sugestão inicial para que possa ser criado nos dois padrões e assim termos essas opções definidas. É claro que não podemos negar que gostaríamos de ter o nosso padrão adotado para que não corramos riscos de ter problemas em nossa conversão do nosso NF-e para trabalhar com o componente ACBr, assim como estamos trabalhando no CT-e. Mas é importante destacar que estamos preocupado em definir a padronização necessária, e conforme a ideia do membro ncc.star, de criamos uma propriedade para definir esse padrão, seria de todo valido, pois assim em qualquer situação iriamos trabalhar no padrão necessário, conforme as regras definidas pela SEFAZ. Certo da atenção de todos, Agradecemos a atenção. Sem mais para o momento, Nilton Olher,

Bom dia a todos, Chegou a resposta da SEFAZ, vou inserir aqui na integrar, até mesmo pra que possam ajudar a definir, pois no email pode gera mais de uma interpretação. Segue abaixo: Prezados, A padronização do arquivo para o processo de compartilhamento é utilizado entre as administrações fazendárias e a RFB, sendo realizado através dos WS específicos de cada serviço descrito no item 11.1 O processo de distribuição deve ser acordado entre as partes (emissor e receptor) respeitando o sigilo fiscal e o padrão de conteúdo de dados definido no item 10.1 do Manual de Orientação. Portanto, deverá ser disponibilizado para o tomador o mesmo conteúdo do CT-e enviado para a SEFAZ autorizadora, complementada com a informação da Autorização de Uso. O nome do arquivo XML final para Distribuição, segue a mesma padronização do Programa Emissor de NF-e. Consulte o site nacional da NF-e / perguntas frequentes / Tópico Programa Emissor de NF-e (9 questões)/ Como obter a NF-e do Software Emissor de NF-e para enviá-la ou disponibilizá-la a meu cliente? Por fim, visando facilitar o processo de guarda dos arquivos pelos legítimos interessados, criou-se uma nomenclatura padronizada para os diversos tipos de arquivos utilizados pelo sistema CT-e em transito. Para esta tarefa deverá ser adotada a nomenclatura de acordo com item 5.2 do Manual. Para a distribuição segue a orientação adotada a nomenclatura de acordo com item 11.1 do Manual, esta padronização de nomenclatura visa facilitar o uso do aplicativo visualizador de DF-e, no processo de possíveis autenticações desses arquivos pelos agentes em campo. Att., SEF/SAIF/Divisão de Escrituração Digital

Realmente não encontrei nos exemplo! No exemplo esta usando o XML para Cancelar! Desde já Antecipo agradecimento, Nilton Olher

É possível cancelar um CT-e sem ter o XML de Origem? Isto é, o XML gerado para o CT-e não foi salvo, qual seria o procedimento para cancelar esse CT-e? Sem mais para o momento, Agradeço a atenção, Nilton Olher

Boa tarde a todos, Reenviamos um Email para SEFAZ detalhando os dois tópicos, numa tentativa que eles façam um posicionamento mais direto no caso em especifico. Ainda estamos no aguardo do posicionamento deles. Vimos o posicionamento ncc.star, e em relação a mudar o nome da propriedade nomexmlpadrao pode ser mudado perfeitamente, e até mesmo a ideia de inserir uma propriedade pra definir os campos que deverão ser usado para gerar o nome. De qualquer forma, antes de mais nada vamos aguardar o posicionamento da SEFAZ novamente. sem mais para o momento, Nilton Olher

Bom tarde Italo, Sabemos da limitações desse programa, estamos falando apenas da questão de nomes, conforme email enviado para a SEFAZ, e neste tópico, fala especificamente de nome para envio para o cliente final, assim como a resposta da SEFAZ! Será gerado um arquivo cujo nome será composto: pelo número do protocolo de autorização (15 dígitos), seguido da versão do leiaute (ex: v2.00), e acrescentado com a expressão "-procNFe". Exemplo de nome de um arquivo de NF-e autorizado exportado: "123456789012345_v2.00-procNFe". Mais uma vez Agradeço a atenção. Nilton Olher

Bom dia Italo, Temos novidade em relação a questão de nomes, enviamos um email para SEFAZ, e obtemos a seguinte resposta: - O nome do arquivo XML final para Distribuição, segue a mesma padronização do Programa Emissor de NF-e. Consultem o site do SEFAZ NFE, nas perguntas frequentes. - Tópico Programa Emissor de NF-e (9 questões) - Como obter a NF-e do Software Emissor de NF-e para enviá-la ou disponibilizá-la a meu cliente? http://www.nfe.fazenda.gov.br/portal/perguntasFrequentes.aspx?tipoConteudo=bh2adesjFPw=

Boa tarde Italo, Já havíamos lido e estudado esse item: 5.2 da página 77, e em nossa interpretação esses são nomes para todos os arquivos XMLs gerado em transito, isto é no processo, em nenhum momento é citado os XMLs protocolados e pronto para distribuição. Porém deixa realmente uma interpretação igual a relatada por você. Se partimos que a interpretação da pagina 77 item 5.2, seja a correta iremos proceder com definido. De qualquer forma será bom ouvir mais opiniões. Agradeço a atenção de todos. Nilton Olher

Fizemos a Alteração para salvar o Arquivo XML final de Distribuição de acordo com o padrão de nomenclaturas do manual. E para que seja de forma opcional foi criado uma propriedade dentro das propriedades de configurações, inserido uma propriedade NOMEXMLPADRAO, e assim, ficando opcional caso a propriedade seja True será gerado no padrão manual caso contrario irá gerar conforme o padrão definido pela ACBr. Esta alteração foi realizada apenas no componente ACBRCte, mas gostaria que fosse estendido ao componente ACBrNFe. Segue em anexo as Units alteradas inclusiva com alteração enviada em post anterior. Os pontos de alterações esta: 1- // Alteração Realizada por Nilton Olher em 10/01/2013 2- // Alteração Realizada por Vanessa Karla em 15/01/2013 Estamos a disposição para maiores esclarecimentos, sem mais para o momento, Agradecemos a Atenção, Nilton Olher. ACBrCTeConfiguracoes.pas ACBrCTeWebServices.pas ACBrCTeConfiguracoes.pas ACBrCTeWebServices.pas

Bom, quando desenvolvemos o nosso NF-e, tivemos problemas com a questão de nome do Arquivo XML, e aí na época consultamos a SEFAZ, que nos orientaram a utilizar a nomenclatura de Acordo com o definido no Manual Item 11. Compartilhamento de Informações do CT-e entre Órgãos Públicos, onde no subitem 11.1 Processo de Compartilhamento, fala sobre essa nomenclatura. 11.1 Processo de Compartilhamento O compartilhamento de documentos entre as SEFAZ e a RFB será realizado através dos Web Services de compartilhamento de Documentos Fiscais Elerônicos, seguindo a padronização de nomes de arquivos que segue: · CT-e: Número do Protocolo + “_v” + [Versão do arquivo de schema com 5 posições (ex: 99.99)] + “-procCTe.xml”. Exemplo: 143061234567890_v01.00-procCTe.xml. · Cancelamento de CT-e: Número do Protocolo + “_v” + [Versão do arquivo de schema com 5 posições (ex: 99.99)] + “-procCancCTe.xml”. Exemplo: 143061234567890_v01.00-procCancCTe.xml. · Inutilização de numeração de CT-e: Número do Protocolo + “_v” + [Versão do arquivo de schema com 5 posições (ex: 99.99)] + “-procInutCTe.xml”. Exemplo: 143061234567890_v01.00-procInutCTe.xml. · Carta de Correção de CT-e: Número do Protocolo + “_v” + [Versão do arquivo de schema com 5 posições (ex: 99.99)] + “-cartCorCTe.xml”. As nomenclaturas utilizado pelo componente ACBr, difere primeiramente pela parte principal do nome ser a Chave de Acesso e não o Número de Protocolo, sem a identificação da versão, e no caso do CT-e normal a parte fixa esta “-CTe.xml” e não “-procCTe.xml”.

Me desculpe a demora para resposta! Em relação a nomenclatura, conforme o manual é uma orientação da SEFAZ para padronização, mas realmente até o momento não há uma exigência, e sim uma orientação! Entendemos que através desta padronização podemos ter uma melhor organização e controle dos arquivos gerados. Em nosso sistema por exemplo fazemos um controle dos arquivos enviado e gerados, de acordo com o recomendável pelo manual. E como já comentando anterior nossa maior preocupação é que já utilizamos essa padronização em nossa emissão de NF-e, com desenvolvimento próprio e na versão Delphi 7, e iremos migrar para Delphi XE, e gostaríamos de trabalhar com o componente ACBrNFE também, mas diante das informações e controle que já temos, esse ponto poderá ser um transtorno para realizarmos essa migração. Entendemos que o padrão atual do componente é utilizado pela maioria que utiliza o componente, sendo assim se houver possibilidades de implementar a padronização indicada no manual, haverá necessidade de ser opcional já que da mesma forma que realizamos o controle de acordo com a orientação do manual, poderá haver outros que já faz esse controle de acordo com a padronização atual do componente.

Conforme solicitação segue unit com as referidas alterações, no topo foi colocado o comentario sobre a alteração, e nos pontos onde houve a alteração. Reforçamos que não realizamos a modificação em relação ao nome do arquivo XML final de envio (Xml com protocolo), pois nos faltou um maior conhecimento da rotina, pra que não houvesse transtorno no procedimento, sendo assim, solicitamos a avaliação, e o possivel atendimento da mesma, ficando assim totalmente igual o manual SEFAZ. Mais uma vez, nosso muitissimo obrigado. Nilton Olher ACBrCTeWebServices.pas

Em relação a Padronização do Nome do arquivo XML, falamos do arquivo XML de Distribuição, e a padronização conforme Manual: 11.1 Processo de Compartilhamento O compartilhamento de documentos entre as SEFAZ e a RFB será realizado através dos Web Services de compartilhamento de Documentos Fiscais Elerônicos, seguindo a padronização de nomes de arquivos que segue: · CT-e: Número do Protocolo + “_v” + [Versão do arquivo de schema com 5 posições (ex: 99.99)] + “-procCTe.xml”. Exemplo: 143061234567890_v01.00-procCTe.xml. · Cancelamento de CT-e: Número do Protocolo + “_v” + [Versão do arquivo de schema com 5 posições (ex: 99.99)] + “-procCancCTe.xml”. Exemplo: 143061234567890_v01.00-procCancCTe.xml. · Inutilização de numeração de CT-e: Número do Protocolo + “_v” + [Versão do arquivo de schema com 5 posições (ex: 99.99)] + “-procInutCTe.xml”. Exemplo: 143061234567890_v01.00-procInutCTe.xml. · Carta de Correção de CT-e: Número do Protocolo + “_v” + [Versão do arquivo de schema com 5 posições (ex: 99.99)] + “-cartCorCTe.xml”.

As alterações que fizemos foram simples, foram nos procedimentos de Cancelamentos e nos procedimentos de Inutialização, retirando a opção de FConfiguracoes.Arquivos.Salvar nos arquivos XMLs em transito. function TNFeCancelamento.Executar - Comentamos a parte if FConfiguracoes.Arquivos.Salvar then FConfiguracoes.Geral.Save(FNFeChave+'-ped-can.xml', FDadosMsg, FConfiguracoes.Arquivos.GetPathCan ); if FConfiguracoes.Arquivos.Salvar then FConfiguracoes.Geral.Save(FNFeChave+'-can.xml', FRetWS, FConfiguracoes.Arquivos.GetPathCan ); function TNFeInutilizacao.Executar: Boolean; - Comentamos a parte if FConfiguracoes.Arquivos.Salvar then FConfiguracoes.Geral.Save(StringReplace(FID,'ID','',[rfIgnoreCase])+'-ped-inu.xml', FDadosMsg, FConfiguracoes.Arquivos.GetPathInu); if FConfiguracoes.Arquivos.Salvar then FConfiguracoes.Geral.Save(StringReplace(FID,'ID','',[rfIgnoreCase])+'-inu.xml', FRetWS, FConfiguracoes.Arquivos.GetPathInu); Agora em relação a padronização do nome do arquivo final não chegamos a mexer. Mais muito obrigado. Nilton Olher

Bom dia, boa tarde e boa a noite, conforme for a hora! rsrsrsrs Primeiramente venho mais uma vez agradecer a todos que Contribuirão com esse trabalho esplendido a qual nos ajudaram demais nesse projeto do CTe, e esse agradecimento faço aos que idealizaram o projeto, aos que fazem esse projeto acontecer, mas também a todos que de alguma forma contribuirão pra chegar onde esta hj, desde uma simples dúvida até aos que buscam aprimoramento e descobrem bugs, em sintase todos envolvido nesse trabalho. Bom, mas vamos ao que realmente interessa! Verificamos alguns pontos e sendo que um deles cheguei até a verificar com Italo, fizemos a alteração aqui, mas seria melhor se pudéssemos padronizar no componente, em relação ao local de salvar os XMLs gerados no processo. Temos 02 locais de definir os Paths no Componente, um é em Configurações.Arquivos e o Outro em Geral, ao nosso entender vemos que seria necessário padronizar a utilização ao salvar os XMLs, isto é, no Path definido em Geral.PathSalvar deveria salvar todos os XMLs gerados durante o processo de transição de envio, seja do conhecimento normal, de um cancelamento, de inutilização ou até das consultas, e nos Paths definido em Configurações.Arquivos deveria somente receber os XMLs final. O Segundo ponto esse vemos que seja muito mais importante, observamos que o nomes do arquivo final gerado, esta fora do padrão recomendado pelo o Manual, e em nosso caso isso tem nos acarretados problemas maiores, pois já temos o padrão do Manual aplicado no NFE, não componente ACBr, e que em nossa próxima versão gostaríamos de utilizar o componente ACBr, mas esse tem sido o grande empasse. Sendo assim vimos essa necessidade de colocar o nome dos XMLs final de acordo que o Padrão do Manual. No mais é isso pessoal, espero que possa ter um respaldo de todos para que nossas observações seja entendidas e posta em pratica. No mais muito obrigado. Nilton Olher

Muito Obrigado pela implementação.

Sim, resolve sim!