EMBarbosa

Na verdade, colocar no final traria problemas ainda maiores quando a SEFAZ criasse outro valor... Acho que a questão aqui é discutir se é viável. Estamos apenas expondo as preocupações.

Boa tarde. Primeiro, você vai precisar debugar e ver exatamente em qual linha do código acontece o Access Violation. Daí tentar descobrir o motivo do Access Violation. Só então vai dar pra ter uma posição, porque não conseguimos reproduzir daqui. Eu dei uma olhada, mas não consegui identificar nada aqui. Se o motivo for esse, então talvez alguma dessas dlls estejam repetidas no seu HD. uma aplicação usa uma e a outra use outra. Mas isso não dá pra descobrir por esses logs porque os logs só mostram os nomes das dlls e não os caminhos.

Gustavo, o maior problema é a quebra do código alheio. Nós nos preocupamos com isso. Veja bem, um monte de gente guarda no banco o valor do enumerado ao invés de guardar no banco o valor da tag. Daí na hora de converter de volta, qualquer alteração na ordem dos enumerados vai dar problema para os valores que já estão no BD. Nem é tanto pela alteração do código em si, que faz algum sentido. Mas pela retrocompatibilidade.

Olá Juliano Rosa. Agradecemos sua contribuição. Mas eu não entendi a necessidade dela. A adição do parâmetro AOwner não parece ser necessário. Sei que mencionou a padronização como motivação, ou seja, para ficar semelhante aos registros H020 e H030. Mas nem mesmo nos registros H020 e H030 esse parâmetro parece ser necessário. Na verdade, acho que o correto seria remover deles. A menos que você tenha percebido alguma coisa que eu deixei passar. Poderia confirmar se seria apenas isso mesmo?

Muito obrigado pela contribuição. Fiz a implementação baseada nela com o objetivo principal de deixar os pacotes padronizados. No entanto, não enviei os arquivos .res e também outras modificações que julguei desnecessárias ou incorretas. Subi as alterações para o SVN na Revisão 21515. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Por outro lado, tenho que concordar com os colegas acima na questão do seu objetivo das alterações. Se a questão é não ficar recompilando os arquivos do ACBr, é muito melhor remover do "search path" as entradas do ACBr que contem os arquivos ".pas". De qualquer forma, mais uma vez, obrigado.

Não entendi o problema. Se as margens estão sempre configuradas com "5", "6" e "8", a impressão vai mudar na comparação da versão anterior e no atual. Afinal uma usa cm e outra milímetros.

Qualquer uma das duas opções é viável. Atualmente, de modo geral as pessoas preferem a DLL por poder ter mais controle.

Ok... Vou tentar verificar mais uma vez.

Joia. Fico feliz em ajudar. Bom trabalho por aí.

Olá, Essa informação você encontra na própria Nota Técnica na coluna "Ocor." (ocorrência). Você pode ver na imagem abaixo: O campo cEAN tem uma ocorrência 1-1. Isso significa que o campo precisa aparecer no mínimo 1 e no máximo 1 vez. Já o campo cBarra tem uma ocorrência 0-1. Isso significa que o campo precisa aparecer no mínimo 0 e no máximo 1 vez. Ou seja, ele pode não ser informado por ter ocorrência mínima de 0 (zero).

De certa maneira, a "venda no balcão" não deixa de ser venda na "plataforma própria" da loja. Até onde sei, no momento só em homologação. Mas essa informação é bom sempre você conferir na NT e na Sefaz da sua UF.

Se eles mesmos atendem os clientes presencialmente, então seria: indicador de presença: 1=Operação presencial intermediador/marketplace: 0=Operação sem intermediador (em site ou plataforma própria)

Baseado nessa discussão, criamos um tópico na nossa base de conhecimentos sobre o assunto. Vejam:

Boa tarde, Estou adicionando na minha fila de análise. Vou tentar de dar um retorno durante a semana que vem.

Olá pessoal. Levanta aí que vamos falar da atualização do ACBr. Resolvemos criar esse tópico devido a muitas dúvidas relacionadas a isso e depois de um debate interessante sobre o assunto. Principalmente quando entra a questão de quando atualizar o programa no cliente. Na sua empresa, vocês devem entender que o Projeto ACBr tem uma forma de desenvolvimento própria. Vocês não precisam seguir o mesmo pra seu desenvolvimento porque os objetivos talvez sejam diferentes. Mas vamos entrar em detalhes depois... agora... A pergunta mais importante: Quando Atualizar o ACBr? Podemos resumir no seguinte: atualize o o mais frequentemente quanto possível. Mas a resposta completa vai depender da sua equipe, do tamanho da empresa e das alterações que foram disponibilizadas. A chave é que vocês devem se sentir como desenvolvedores do ACBr. O código é open-source e é também de vocês. Afinal, ele roda na sua aplicação e afeta seus clientes. Além disso, geralmente as funções que usamos do ACBr são cruciais no sistema. Mesmo que vocês sejam desenvolvedores que utilizam as libs ou o ACBrMonitore e, tenham a impressão que não se encaixam nesse perfil, os princípios delineados aqui podem ajudar. Como é o fluxo de desenvolvimento do ACBr? No Projeto ACBr, em especial no desenvolvimento dos componentes, nós usamos um fluxo de desenvolvimento que não é totalmente orientado a versões. Esse fluxo é algo mais parecido com o trunk based development do que com um GitFlow. Para quem vê de fora, isso significa basicamente: Controlamos a versão dos componentes via o versionamento do próprio SVN. Assim, podemos reproduzir qual versão uma pessoa tem instalada apenas sabendo a revisão do código que ela usa; Não ficamos criando branches para desenvolvimento de funções e recursos. Nós temos um repositório branches, mas não ficamos desenvolvendo recursos nos componentes atuais nele a menos que seja estritamente necessário (Por exemplo: um refactoring total do componente); Quem usa os componentes tem os novos recursos, correções, e respostas muito mais rapidamente do que teria de outra forma; Pra não delongar mais nisso (que não é o foco desse artigo), se quiser ver um exemplo de empresa que usa esse tipo de desenvolvimento, recomendo esse artigo "Moving away from GitFlow" (de Niklas Gray). Mas isso funciona pra nós em especial porque (a) quem usa os componentes também é desenvolvedor e (b) temos uma resposta muito rápida quando acontecem problemas. Assim, isso não significa necessariamente que vai funcionar na sua empresa. Voltando a pergunta importante... Como estabelecer uma rotina de avaliar se e quando deve ser feita a atualização do ACBr? Se vocês não tem nenhuma rotina pra avaliar quando e se devem atualizar o ACBr, sugerimos que estabeleçam uma. A princípio, sugerimos o seguinte: Leiam os logs do SVN pelo menos uma vez por dia. Não é preciso atualizar para ler o log. Basta usar o "Show Log" do SVN. 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 e teste seu desenvolvimento. 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. É 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. Nota: 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. O último a ser atualizado é o servidor de Build. A partir daí já entra no "deploy", quer dizer, na entrega do software para o cliente. Como impactar da menor maneira possível meu cliente com meu software após atualização do ACBr? Gostaria de enfatizar que você precisa ter estratégias diferentes. Uma para quando você deve atualizar o ACBr (desenvolvimento) e uma para quando você deve atualizar o seu sistema no seu cliente (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 diferentes que você precisa ter em mente. Para reduzir o impacto nos clientes, faça o "deploy" de forma escalonada. Quer dizer, instale a nova versão primeiro em clientes selecionados. A princípio, escolha apenas dois, três ou no máximo quatro. Quanto mais crítica a alteração, mais seletivo você precisa ser. 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) Só depois de um tempo de teste nesses clientes, envie a nova versão para os outros. Você pode continuar escalonando a entrega avaliando o tamanho da sua equipe e número de clientes que possui. De qualquer maneira você precisa avaliar o que é melhor pra sua empresa. Mas como decidir? Muitas questões devem ser levadas em conta. É verdade que ninguém deveria ficar desesperado para instalar uma nova versão se não teve condições de 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, da equipe de suporte e até o plano de negócios da empresa. Mas por outro lado, 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? Sua equipe tem tamanho suficiente pra cuidar de várias versões diferentes? Temos certeza que a análise dessas questões vão ajudar vocês a tomarem boas decisões. Bom trabalho por aí.

Se não me engano "Alt Gr" é o mesmo que "Ctrl+Alt".

Isso já está disponível sim. Vou deixar aqui o tópico de anúncio do ACBrPagFor: Fechando o tópico para evitar maiores misturas de assuntos.

Oi Jéter, agradeço a ajuda. Não consegui reproduzir aqui, então qualquer informação pra gente tentar descobrir ficaremos agradecidos.

O ACBrInstall não vai corrigir o problema gerado anterior. Você já tinha corrigido o path antes de instalar? Qual a versão do ACBrInstall? Hmm... Nessa versão eu não fiz testes, porque ainda não recebemos. Testei apenas no 10.4.1.

Pode acontecer de acontecer um erro de Access Violation (AV) ao abrir o Delphi após instalar o ACBr como na imagem abaixo: Esse erro se dá quando o Delphi carrega uma BPL do ACBr mas encontra uma outra versão da BPL que ela depende. Pode acontecer por exemplo quando você instala algum componente no Delphi diretamente por meio do pacote e depois executa o processo de instalação usando o ACBrInstall. Solução: Para corrigir o problema basta excluir as BPLs duplicadas. Geralmente elas estão no caminho padrão de BPLs do Delphi. Exemplo: Por exemplo assumindo o Windows 10 e versões do Delphi mais recente esse caminho seria: C:\Users\Public\Documents\Embarcadero\Studio\NN.N\Bpl Onde o NN.N é uma versão do Delphi Por exemplo, no erro que aconteceu da imagem acima haviam BPLs do ACBr na seguinte pasta: C:\Users\Public\Documents\Embarcadero\Studio\20.0\Bpl Removendo essas BPLs o Delphi volta a funcionar corretamente.

Essa é a lei da LGPD: http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/L13709.htm A questão é: Você consegue cumprir ela com os recursos atuais do seu sistema? O vídeo acima citado fala bem sobre os detalhes.

Resumo dos pontos principais do Vídeo sobre "A implantação da NFC-e em SC" Visulizar Arquivo Esse documento é um resumo dos pontos principais salientados e discutidos no vídeo do fisco de SC sobre a implantação da NFC-e em SC na data de 23/10/2020. Esse aqui é o Vídeo: https://www.youtube.com/watch?v=6GTeSpc28Xs Se você vai implementar NFC-e em SC usando o modelo PAF-NFC-e esse documento pode ajudar. Se viu o vídeo, esses pontos principais vão ajudar a relembrar o que era mais importante. Se não viu o vídeo, então esses pontos vão te dar uma ideia daquilo que foi discutido. De qualquer maneira, você sempre vai ter em mãos um resumo daquilo que realmente importa na implantação da NFC-e, de como o fisco encara isso. É um documento importante pra ajudar a tomar decisões sobre a implementação. Autor EMBarbosa Enviado 19-02-2021 Categoria Utilitários - PRO  

Veja a documentação disponibilizada pela SEFAZ no grupo deles. Não use o Ato Cotepe como orientação porque ele está desatualizado para SC nesses requisitos relacionados ao Bloco X.

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