EMBarbosa

A documentação parece estar ligando o DANFe a emissão/autorização da NFC-e e não simplesmente a impressão. Mas posso estar enganado. Assim, sugiro mais uma vez entrar em contato com a SEFAZ. É melhor tirar essas dúvidas o quanto antes no seu processo de desenvolvimento.

@foleyjf , @Juliomar Marchetti, @Jéter Rabelo Ferreira e outros interessados no assunto. Peço desculpas pela demora em responder aqui, mas realmente pensei que isso teria sido resolvido bem antes. Deixa eu tentar explicar o que tem acontecido e o porquê dessa demora pra enviar ao SVN a correção. É o seguinte: o código da JCL que usamos para acessar os dados da IDE instalada não está totalmente pronto pras novas versões do Delphi, em especial na questão de multiplataformas. Tivemos que implementar várias alterações no código deles. Mas de qualquer maneira esse não foi o problema maior. As versões mais novas do Delphi usam, além do registro do Windows um arquivo ".proj" para armazenar configurações de compilação (por causa do MSBuild). A JCL aparentemente já trabalhava com esse arquivo corretamente. A IDE pega do registro e atualiza esse arquivo com os dados da plataforma durante o uso. O que acontece é que, em algumas circunstâncias esse arquivo ainda não foi atualizado. Não há, até onde eu sei, uma documentação sobre quando esse arquivo é atualizado. Então eu demorei muito para conseguir reproduzir o problema. Além disso, por duas vezes eu fiz correções que acabaram por produzir um efeito indesejado... Então nem enviei ao SVN depois de ter avaliado o resultado. Claro que não queremos causar outros efeitos indesejados na instalação do Delphi de ninguém. Então estou sempre tentando testar o melhor possível essa questão. Por fim, por algum motivo, o ACBrInstall não estava conseguindo pegar os dados da plataforma diretamente do registro. Então fiquei trabalhando no código da JCL pra tentar resolver. Isso tomou bem mais tempo que imaginei. Pra completar a "saga", por algum motivo meu acesso de committer estava sendo recusado pelo Source Forge. Então, estou enviando as alterações que fiz esses dias ao SVN por partes e, assim que terminar deve estar resolvido.

Bom dia. Estou adicionando a nossa fila de análise. Logo a gente entra em contato.

Mas não esqueça do que eu escrevi no final. Se não teve tempo, sugiro ler o artigo que eu citei.

Nesse caso, precisamos entender melhor o que você e sua equipe estão discutindo. O que vocês estão discutindo? Vocês estão discutindo a atualização do ACBr ou o "deploy", que é o envido de versões aos clientes? Vocês precisam de uma estratégia de "desenvolvimento" e uma estratégia de deploy. Tudo bem que as duas estratégias podem ser interligadas, como é o caso quando se usa um sistema de "Implantação Contínua". Mas são duas coisas bem diferentes. Não vou dizer que você está errado nas sua posição. Porque não está. Na verdade, talvez não tenha certo ou errado aqui. E claro, ninguém deveria ficar desesperado para instalar uma nova versão sem fazer testes. Também, antes de enviar uma versão aos clientes é preciso levar em conta a quantidade de clientes, o tamanho da equipe de desenvolvimento e suporte e até o plano de negócios da empresa. Por outro lado, acho que as seguintes perguntas precisam também ser analisadas: Só se envia uma nova versão ao cliente para resolver problemas? Não são apresentadas ao cliente os novos recursos como algo que facilita a vida dele? Não seria muito mais interessante comercialmente se o programa tivesse sempre novidades para cativar o usuário? Não será muito mais difícil encontrar e resolver um problema se de uma versão para outra houverem muitas alterações no código? Que controle se faz de versão do software que está instalado no cliente? Consegue-se facilmente reproduzir no ambiente de desenvolvimento? Vou deixar esse link de artigo aqui que eu achei muito interessante de um pessoal que saiu do "GitFlow" e foi pro "Trunk Based Development". Leia também os comentários onde alguns categoricamente não concordam. É um artigo pra pensar no desenvolvimento. https://www.gamasutra.com/blogs/NiklasGray/20170927/306445/Moving_away_from_GitFlow.php Enfim, eu disse implicitamente antes, mas agora vou falar explicitamente. Não estou dizendo que uma maneira é melhor do que a outra. Cada empresa precisa pesar as vantagens e desvantagens e decidir o que é melhor para empresa, sua equipe e seus clientes. Não leve em conta só a sua equipe. Mas também, não leve em conta só os clientes. Isso poderia fazer sua equipe sofrer.

Acho que a ideia é: atualize o o mais frequente quanto possível. Mas a resposta completa vai depender da sua equipe, do tamanho da empresa e das alterações que foram disponibilizadas. Acho que a chave é que vocês devem se sentir como desenvolvedores do ACBr. O código é também de vocês. Afinal, ele roda na sua aplicação, e afeta seus clientes. Mas esse é o meu ponto de vista particular. Voltando a sua pergunta, por experiência própria, sugiro o seguinte: Leiam os logs do SVN pelo menos uma vez por dia. Não é preciso atualizar para ler o log. Ao ler o log do SVN, verifique se: Alguma alteração feita afeta seus clientes em produção? (correção de bug, alteração de legislação, etc...) Algum novo recurso que você quer utilizar foi implementado? Se são poucas alterações e elas não são essenciais, você (ou alguém na sua equipe) tem tempo para testar? São muitas alterações que foram feitas? Já passou muito tempo desde que foi feita a última atualização? Por exemplo mais de 3 semanas? Caso a resposta a qualquer pergunta acima seja "sim", atualize. No mínimo você vai estar mantendo o código do seu aplicativo com o mínimo de alterações possíveis. Então quando surgir uma situação que vocês precisem atualizar com urgência, não vai haver uma grande quantidade de trabalho acumulado. Caso negativo, siga com as suas tarefas. Vale lembrar também que nem toda atualização precisa de uma reinstalação. Você precisa reinstalar quando: As alterações envolvem partes visuais dos componentes; Os fontes não são recompilados ao fazer um build em sua aplicação; Depois de atualizar, teste as partes de sua aplicação que usam os componentes modificados assim que possível. Primeiro na sua máquina de desenvolvimento, depois em outras máquinas. Por último no servidor de Build. Faça o "deploy" de forma escalonada. Quer dizer, instale a nova versão primeiro em clientes selecionados. Escolha apenas dois, três ou no máximo quatro a princípio. Quanto mais crítica a alteração, mais seletivo você precisa ser. Depois de um tempo, envie a nova versão para os outros. Dentre sua carteira de clientes, minha sugestão é para escolher aqueles que: Precisam da "novidade" apresentada no novo executável Tem um movimento menor (e assim darão um grau menor de dor de cabeça caso algum imprevisto aconteça) Ficam mais próximos de sua empresa (posso deslocar um técnico ou até mesmo um "dev" pra lá rapidamente se realmente necessário, nem que seja virtualmente?) São mais pacientes e compreensivos (paciência nunca é demais, apenas cuide de não abusar deles) Nota: É claro que, se vocês estão no meio de uma situação que precisa que todo o desenvolvimento fique focado no produto de vocês, talvez não seja possível atualizar o ACBr. Por exemplo, pode ser que um problema no software esteja exigindo a atenção urgente de toda equipe. Mas geralmente, pelo menos um dev deve conseguir dar uma lida nos logs e fazer a avaliação se é necessário ou não atualizar.

Poderia explicar melhor essa parte?

Então, não sei se você entende a diferença, mas começando pelo OLE: Aqui você está utilizando OLE, (nome antigo, agora é apenas automação), para automatizar o Office. É como se você tivesse acesso as dlls da aplicação pra lançar os comandos. Isso permite muita coisa. Por outro lado, precisa ter certeza que os objetos OLE que você está utilizando são compatíveis com o que está instalado na máquina e sua aplicação consegue encontrar. Se você não estiver usando a versão correta, pode acontecer isso que está dizendo. Além de atualizar seus objetos OLE, seria bom se seu código tratasse os erros levantados para verificar o que está acontecendo. No código acima não dá pra ver tratamento de erros então não sei se você está fazendo. Caso não, você deve encontrar na internet material sobre o assunto. Nesse código, você está executando um comando do Shell. Está basicamente executando o outlook pelo "prompt". Então precisa conhecer os parâmetros do Outlook por linha de comando nessas novas versões. Geralmente basta entrar no prompt, na pasta do outlook e digitar "outlook /?". Mas caso contrário, tem que procurar a documentação. Achei esse link aqui, espero que ajude: https://support.microsoft.com/en-us/office/command-line-switches-for-microsoft-office-products-079164cd-4ef5-4178-b235-441737deb3a6#ID0EAABAAA=Outlook

Bom dia. Para entender o que é o MRE é você precisa ler o requisito entendendo o bloco que ele se encontra. O REQUISITO XVII pertence ao bloco: Ou seja, os requisitos desse bloco são para sistemas que permitem o lançamento de DAV e Pré-venda por meio de uso de dispositivos móveis (celulares, tablets, e afins), Internet ou outros similares. Podemos falar então de modo generalizado que o sistema é "modularizado". Quero dizer, tem um "módulo" na empresa, outro "módulo" rodando num celular ou via internet. Isso vale mesmo que o "módulo" que estamos falando seja uma página "html" gerada pelo seu servidor para rodar no browser do dispositivo. Nota: Se o seu sistema não faz isso, quer dizer não tem esse recurso de lançamento de davs e pré-vendas por fora, é só ignorar esse bloco. Agora com isso em mente, vamos ler o parágrafo desse requisito novamente: Respondendo então sua primeira pergunta, esse Módulo de Recepção Externa do PAF-NFC-e (MRE) é desenvolvido por vocês, sendo parte do seu PAF-NFC-e. Esse "módulo" vai receber as requisições feitas por fora do seu Sistema de gestão e tem que seguir os requisitos delineados. Até onde eu sei, a Sefaz não faz distinção com front-end e back-end. Ela entende "sistema local" e "em rede". Seu sistema parece funciona em rede, então é considerado requisição externa. Se estiver tudo na mesma "máquina" é considerado local. Mais de uma "máquina", rede. É uma explicação meio grosseira, mas acredito que você consiga entender. Por via das dúvidas, no caso específico dessa dúvida, eu sugiro vocês levarem o questionamento a Sefaz de SC. Eles podem, ou não, te dar uma orientação um pouco diferente. Sim. Todas essas requisições são externas. Elas não são feitas no seu Sistema de gestão. Então é externa.

Que tipo de código você usa para abrir o Outlook?

Se eu entendi bem sua dúvida, você só irá receber o xml completo depois de você fazer a manifestação. Veja esse tópico: https://www.projetoacbr.com.br/forum/topic/46730-como-obter-o-xml-do-fornecedor/?tab=comments#comment-377650

Não. A imagem não mostra que essa versão está instalada no Delphi 7.

A imagem mostra claramente (letras azuis logo na frente da versão do Delphi 7) que você precisa instalar a JCL de versão 2.2 ou superior no Delphi 7 antes de instalar a JVCL.

Se eu entendi bem: Antes de escrever o registro 2110, sua aplicação já deve saber: Se a apuração será de ressarcimento e/ou complemento Se vão ser gerados registros 2121 ou 2120 Sabendo disso com antecedência, seria possível preencher esse campo conforme as regras que você postou. Mas, conforme o Juliomar mencionou acima, em caso de dúvidas, o melhor mesmo é contatar um contador experiente nessa área.

Sugestão que pode parecer boba, mas funciona: Vá num parque aquático e veja como eles fazem com essa questão de cartão. Daí, faça melhor.

Possível solução em:

até onde estou sabendo, por enquanto, ainda está funcionando... Veja esse tópico sobre como configurar tanto o ACBrMail como a conta de e-mail:

2.2 - Permaneça no assunto - Quando tiver uma dúvida diferente do assunto no tópico, poste em novo tópico. Não use algo equivalente a "aproveitando o gancho... [dúvida não relacionada com o tópico aqui]". Favor leia as regras do fórum.

Nesse caso, é altamente recomendado que você entre em contato com eles. Com certeza, se o problema for do lado deles, eles vão agradecer o contato porque isso pode estar gerando problema para um número muito grande de pessoas.

Essa correção não gera efeitos colaterais, mas também não parece fazer muito sentido. Pelo menos não para o problema de "out of memory". Por favor, anexe um arquivo xml que gere o problema para que possamos verificar.

Moderação: Tópico dividido desse outro abaixo:

Então, é isso que eu disse, não tem nenhuma diferença entre o que está no SVN e o seu arquivo nessa linha. Veja: Então acredito que seu código já esteja no SVN. Só preciso de uma confirmação para que possamos fechar esse caso.

Apesar do problema não ser no ACBr, resolvemos subir a alteração. Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 21247. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Mais um motivo pra ficar atento a como o software está consumindo os webservices.

Fortes errado e desatualizado... o certo é esse do git: